Transcript WEB SERVICE SECURITY

WEB SERVICE SECURITY
1
Lecturer: Trần Thị Quế Nguyệt
Students:
Trần Trúc Giang
Nguyễn Thị Hòa Bình
OUTLINE
Web Service Introduction
 XACML
 SAML
 Shibboleth

2
WEB SERVICE INTRODUCTION
3
WEB SERVICE INTRODUCTION
Service-Oriented architecture (SOA)
 Web service definition
 Web Service Description Language (WSDL)
 Simple Object Access Protocol (SOAP)
 Universal Description, Discovery and Integration
(UDDI)

4
SERVICE-ORIENTED ARCHITECTURE (SOA)

W3school.com:
SOA is a mechanism that enables organizations to
facilitate communication between the systems
running on multiple platforms
 SOA is a collection of well-defined services, each
individual service can be modified independently of
other services to help respond to the ever-evolving
market conditions of a business
 SOA presents the big picture of what you can do with
web services

5
SOA’S COMPONENTS
6
WHAT ARE WEB SERVICES?
 W3C’s
Definition: a software system designed
to support interoperable machine-to-machine
interaction over a network.
 Web






services:
application components
communicate using open protocols
self-contained and self-describing
can be discovered using UDDI
can be used by other applications
XML is the basis for Web services
7
WEB SERVICES PLATFORM ELEMENTS
SOAP (Simple Object Access Protocol)
 UDDI (Universal Description, Discovery and
Integration)
 WSDL (Web Services Description Language)

8
SOAP (SIMPLE OBJECT ACCESS
PROTOCOL)
SOAP is an XML-based protocol to let
applications exchange information over HTTP.
 Or more simple: SOAP is a protocol for accessing
a Web Service.

SOAP
communication protocol
format for sending messages
communicate via Internet
platform independent
language independent
based on XML
simple and extensible
allows you to get around firewalls
9
WSDL (WEB SERVICES DESCRIPTION
LANGUAGE)
WSDL is an XML-based language for locating
and describing Web services.
 WSDL file:

<?xml version="1.0" encoding="utf-8" ?>
- <definitions xmlns:s="http://www.w3.org/2001/XMLSchema“
..... xmlns="http://schemas.xmlsoap.org/wsdl/">
+ <types>
+ <message name=“addSoapIn">
+ <message name=“addSoapOut">
+ <portType name=“TestWSSoap">
+ <binding name=“TestWSSoap" type=“TestWSSoap">
+ <service name="TestWS">
</definitions>
10
UDDI (UNIVERSAL DESCRIPTION,
DISCOVERY AND INTEGRATION)

UDDI is a directory service where companies can
register and search for Web services
is a directory for storing
information about web services
UDDI
is a directory of web service
interfaces described by WSDL
communicates via SOAP
is built into the Microsoft .NET
platform
11
12
SECURITY REQUIREMENTS FOR SOAPBASED WEB SERVICES
13
SECURITY REQUIREMENTS FOR SOAPBASED WEB SERVICES
Hold the information related to
the web services
can
Process incoming SOAP
requests
SOAP
Server
Check the incoming SOAP
request
cannot
Distinguish between sensitive
and non-sensitive web services
Perform user authentication,
authorization, and access
control.
14
SECURITY REQUIREMENTS FOR SOAPBASED WEB SERVICES
Solutions
Use a different SOAP
server for each level of
sensitivity
Make the firewall XML
and SOAP aware
The XML
Signature
W3C's XML
Encryption
WS-Security
SAML
XACML
15
XML SECURITY FOR WEB SERVICES



The XML Signature specification is a joint effort of W3C
and IETF. It aims to provide data integrity and
authentication (both message and signer authentication)
features, wrapped inside XML format.
W3C's XML Encryption specification addresses the issue of
data confidentiality using encryption techniques.
Encrypted data is wrapped inside XML tags defined by the
XML Encryption specification.
WS-Security from OASIS defines the mechanism for
including integrity, confidentiality, and single message
authentication features within a SOAP message. WSSecurity makes use of the XML Signature and XML
Encryption specifications and defines how to include digital
signatures, message digests, and encrypted data in a SOAP
message.
16
XML SECURITY FOR WEB SERVICES
Security Assertion Markup Language (SAML)
 eXtensible Access Control Markup Language
(XACML)

17
OUTLINE
Web Service Introduction
 XACML
 SAML
 Shibboleth

18
THE EXTENSIBLE ACCESS
CONTROL MARKUP LANGUAGE
(XACML)
19
XACML
The eXtensible Access Control Markup Language
(XACML) is an XML vocabulary for expressing
access control policies.
 Access control consists of deciding if a requested
resource access should be allowed and enforcing
that decision.
 Access control policies are the criteria for making
access control decisions.
 The XACML core specification defines the syntax
of the language and the rules for evaluating
policies.

20
PREFERRED TERMS
PAP
• Policy Administration Point- The system entity
that creates a policy or policy set
PDP
• Policy Decision Point - The system entity that
evaluates applicable policy and renders an
authorization decision.
PEP
• Policy Enforcement Point - The system entity
that performs access control, by making decision
requests and enforcing authorization decisions.
PIP
• Policy Information Point - The system entity that
acts as a source of attribute values.
21
PREFERRED TERMS
Policy Set
• Policy Set
• Policy
Policy
• Rule
Rule
• Subject
• Resource
• Action
22
PREFERRED TERMS
Resource: Data, service or system component.
 Subject: An actor whose attributes may be
referenced by a predicate.
 Action

An operation on a resource.
 Four kinds of actions: read, write, create, and delete.


Environment: The set of attributes that are
relevant to an authorization decision and are
independent of a particular subject, resource or
action.
23
PREFERRED TERMS
Attribute: Characteristic of a subject, resource,
action or environment that may be referenced in
a predicate or target.
 Context: The canonical representation of a
decision request and an authorization decision.
 Context handler: The system entity that converts
decision requests in the native request format to
the XACML canonical form and converts
authorization decisions in the XACML canonical
form to the native response format.

24
DATA-FLOW DIAGRAM
25
DATA-FLOW DIAGRAM
1
• PAPs write policies and policy sets and
make them available to the PDP.
26
DATA-FLOW DIAGRAM
2
• The access requester sends a request for
access to the PEP.
27
DATA-FLOW DIAGRAM
3
• The PEP sends the request for access to the
context handler.
28
DATA-FLOW DIAGRAM
4
• The context handler constructs an XACML
request context and sends it to the PDP.
29
DATA-FLOW DIAGRAM
5
• The PDP requests any additional subject, resource, action,
environment and other categories (not shown) attributes from the
context handler.
30
DATA-FLOW DIAGRAM
6
• The context handler requests the attributes
from a PIP
31
DATA-FLOW DIAGRAM
7
• The PIP obtains the requested attributes.
32
DATA-FLOW DIAGRAM
8
• The PIP returns the requested attributes to
the context handler.
33
DATA-FLOW DIAGRAM
9
• Optionally, the context handler includes
the resource in the context.
34
DATA-FLOW DIAGRAM
10
• The context handler sends the requested attributes
and (optionally) the resource to the PDP. The PDP
evaluates the policy.
35
DATA-FLOW DIAGRAM
11
• The PDP returns the response context (including
the authorization decision) to the context handler.
36
DATA-FLOW DIAGRAM
12
• The context handler translates the response context to the
native response format of the PEP. The context handler
returns the response to the PEP.
37
DATA-FLOW DIAGRAM
13
• The PEP fulfills the obligations.
38
DATA-FLOW DIAGRAM
14
• (Not shown) If access is permitted, then the PEP
permits access to the resource; otherwise, it denies
access.
39
XACML - ADVANTAGES

According to Sun, XACML has a number of
advantages over other access-control policy
languages:
One standard access control policy language can
replace dozens of application-specific languages
 Administrators save time and money because they
don't need to rewrite their policies in many different
languages
 Developers save time and money because they don't
have to invent new policy languages and write code to
support them. They can reuse existing code

40
XACML - ADVANTAGES
Good tools for writing and managing XACML policies
will be developed, since they can be used with many
applications
 XACML is flexible enough to accommodate most
access control policy needs and extensible so that new
requirements can be supported.
 One XACML policy can cover many resources. This
helps avoid inconsistent policies on different
resources.
 XACML allows one policy to refer to another. This is
important for large organizations. For instance, a
site-specific policy may refer to a company-wide
policy and a country-specific policy.

41
XACML - LIMITATIONS
XACML is verbose and complex in some ways.
 Interactions involving PAP, PIP, etc., are not
standardized.
 Policy administration, policy versioning, etc., are
not standardized.

42
SAML
43
Security Assertions Markup Language
SINGLE SIGN-ON (SSO)
SSO is a property of access control of multiple,
related, but independent software systems.
 With this property a user

logs in once
 gains access to all systems without being prompted
to log in again at each of them.

44
45
WHY CHOOSE SINGLE SIGN-ON?
User needs to remember multiple usernames and
passwords to access different applications on a
network.
 This poses a huge cost for the administration and
support departments.
 Authentication is a horizontal requirement
across multiple applications, platforms, and
infrastructures.

46
WHY CHOOSE SINGLE SIGN-ON?

The objective of SSO
Allow users access to all applications from one logon.
 Provide a unified mechanism to manage the
authentication of users and implement business rules
determining user access to applications and data.


Benefits include the following:
Improved user productivity.
 Improved developer productivity.
 Simplified administration.

47
IMPLEMENTING SSO REQUIRES
Identity Provider (IdP): The system, or
administrative domain, that asserts information
about a subject.
 Service Provider (SP): The system, or
administrative domain, that relies on information
supplied to it by the Identity Provider. It is up to
the Service Provider as to whether it trusts the
assertions provided to it.
 Exchanges of authentication and authorization
data between an IdP and an SP are effected by
means of an XML standard called the Security
Assertion Markup Language (SAML).

48
SAML - INTRODUCTION
The Security Assertion Markup Language
(SAML) standard defines a framework for
exchanging security information between online
business partners.
 As stated in the SSTC charter, the purpose of the
Technical Committee is:

to define, enhance, and maintain a standard XMLbased framework
 for creating and exchanging authentication and
authorization information.

49
SAML – USE CASE

There are four “drivers” behind the creation of
the SAML standard:
Limitations of Browser cookies
 SSO Interoperability
 Web Services
 Federation

50
SINGLE SIGN-ON USE CASE
51
FEDERATION USE CASE
52
SAML COMPONENTS




Assertions: SAML allows for one party to assert
characteristics and attributes of an entity.
Protocols: SAML defines a number of
request/response protocols. The protocol is encoded in
an XML schema as a set of request-response pairs.
Bindings: This details exactly how the SAML
protocol maps onto the transport protocols. For
instance, the SAML specification provides a binding
of how SAML request/responses are carried with
SOAP exchange messages.
Profiles: The core of the SAML specification defines
how the SAML requests and responses are
transported, however, a number of use cases have
been developed that require the formulation of
Profiles that define how the SAML assertions,
protocols and bindings are combined.
53
SAML COMPONENTS
54
SAML - STRUCTURE
Assertions: An assertion consists of one or more
statements.
 For SSO, typically a SAML assertion will contain

a single authentication statement
 a single attribute statement.

55
SAML - STRUCTURE
56
SAML - STRUCTURE

SOAP over HTTP Binding: In environments
where the two communicating end points are
SOAP enabled, then the SOAP over HTTP
binding can be used to exchange SAML
request/query and response protocol messages.
57
SAML - STRUCTURE
58
USE OF SAML IN OTHER FRAMEWORKS XACML
SAML Assertions provide a means to distribute
security-related information that may be used for
a number of purposes. One of the most important
of these purposes is as input to Access Control
decisions.
 The eXtensible Access Control Markup Language
(XACML) is an OASIS Standard that defines the
syntax and semantics of a language for
expressing and evaluating access control policies.
 The work to define XACML was started slightly
after SAML began.

59
PREFERRED TERMS
PDP
• Policy Decision Point - The system entity that
evaluates applicable policy and renders an
authorization decision.
PEP
• Policy Enforcement Point - The system entity
that performs access control, by making decision
requests and enforcing authorization decisions.
60
USE OF SAML IN OTHER FRAMEWORKS XACML

Using SAML and XACML in combination would typically
involve the following steps.
1. An XACML Policy Enforcement Point (PEP) receives a
request to access some resource.
2. The PEP obtains SAML Assertions containing information
about the parties to the request, such as the requester, the
receiver (if different) or intermediaries. These Assertions
might accompany the request or be obtained directly from a
SAML Authority, depending on the SAML profile used.
3. The PEP obtains other information relevant to the request,
such as time, date, location, and properties of the resource.
4. The PEP presents all the information to a Policy Decision
Point (PDP) to decide if the access should be allowed.
5. The PDP obtains all the policies relevant to the request and
evaluates them, combining conflicting results if necessary.
6. The PDP informs the PEP of the decision result.
7. The PEP enforces the decision, by either allowing the
requested access or indicating that access is not allowed.
61
USE OF SAML IN OTHER FRAMEWORKS XACML
62
USE OF SAML IN OTHER FRAMEWORKS XACML
1
• PEP receives a request to access some resource.
63
USE OF SAML IN OTHER FRAMEWORKS XACML
2
• The PEP obtains SAML Assertions. These Assertions
might accompany the request or be obtained directly
from a SAML Authority.
64
USE OF SAML IN OTHER FRAMEWORKS XACML
3
• The PEP obtains other information relevant to the
request.
65
USE OF SAML IN OTHER FRAMEWORKS XACML
4
• The PEP presents all the information to a Policy Decision
Point (PDP) to decide if the access should be allowed.
66
USE OF SAML IN OTHER FRAMEWORKS XACML
5
• The PDP obtains all the policies relevant to the request
and evaluates them, combining conflicting results if
necessary.
67
USE OF SAML IN OTHER FRAMEWORKS XACML
6
• The PDP informs the PEP of the decision result.
68
USE OF SAML IN OTHER FRAMEWORKS XACML
7
• The PEP enforces the decision, by either allowing the
requested access or indicating that access is not allowed.
69
SHIBBOLETH
Denifition
Shib Basic
Shib Architechture
Shib Technical Components
Issures
70
INTRODUCTION
Many resources
Many people
Many locations
hard to manage
access to resources
federations
federated identity
authenticate
provide user attributes
SSO system
Identity Providers
Service Providers
form federations
71
DEFINITION

Shibboleth is an Internet2 Middleware
Initiative project that has created an architecture
and open-source implementation for federated
identity-based authentication and authorization
infrastructure based on Security Assertion
Markup Language (SAML). Federated identity
allows for information about users in one security
domain to be provided to other organizations in a
federation.
 This
allows for cross-domain SSO and
removes the need for content providers to
maintain usernames and passwords.


Identity providers (IdPs) supply user information
service providers (SPs) consume this information and get
access to secure content.
72
HOW IT WORKS?
•
•
Interrealm Attribute-based Authorization for Web Services
An initiative to develop
An architecture
• Policy framework
• Practical technologies to support inter-institutional sharing of
resources
•
•
•
•
•
•
•
•
Based on a federated administration trust framework.
Provides the secure exchange of interoperable attributes in
access control decisions.
Controlled dissemination of attribute information, based on
administrative defaults and user preferences.
Shifts the model from passive privacy towards active
privacy.
Developed with vendor participation - IBM/Tivoli.
Standards Alignment - OASIS/SAML.
Open solution.
73
FEDERATION
Group of institutions
agree
set of policies - practices - standards
For
Authentication
security of components/ exchange use
population of user attributes
Trust model to work between institutions
SPs will accept attributes from any IdP in the
Federation

74
FEDERATED ADMINISTRATION
Leverage local authentication mechanisms
Origin Site
•
•
•
•
•
Must have joined AC
Create default ARP
Identification and
registration of users
Managing attributes
Authenticating users
prior to resource access
Browser User
• Need to know the name
user’s origin domain
• Create specific attribute
release policies
Target Resource
Manager
• Must have joined the
appropriate communities
• Manage policies governing
75
access to the resource
TECHNICAL COMPONENTS
Origin Site
Target Site
Identity Provider
Service Provider
• Handle Server
• Attribute Authority
• Existing assumed:
• SHIRE
• WAYF
• SHAR
• Resource Manager
• Existing assumed:
• Campus directory/ Attribute
store
• Web-ISO
• Web servers
• RM
76
COMPONENTS
If the credentials are valid the
1.In
2.The
3.The
6.The
7.
The
apermission
user
WAYF
Handle
web
user
browser,
issupplies
service
not
Service
authenticated
the
credentials
asks
works
user
the
user
so
tothe
to
The
11.The
12.The
13.
IfACS
ARvalidates
attributes
request
has
are
the
attributes
been
used
handle,
granted
bywith
from
the
SP
Handle
Service
generates
handle
4. Theuser
5.The
user
ischooses
redirected
an institution
toathe
10.The
AR
request
attributes
from
attempts
choose
local
authenticate
SSO
an
to
system
institution
redirected
access
(e.g.
to
username
a ask
resource
(IdP)
to
toWAYF
user
and
to
creates
to
the
determine
AA
user
supplies
aissession
able
whether
to
attributes
and
access
transfers
to the
permit
the
in
the
the
for
it to
the
(IdP).
Handle
Service
ofsupplies
the chosen
IdP.
the the
AA user
of
theand
IdP
using
the
handle.
protected
service.
authenticate
authenticate.
password).
by
at.
handle
form
access
resource.
ofto
to
assertions.
the
thethe
resource.
AR.SP.
ACS of the SP.
77
COMPONENTS
Attribute
Server
Pass Privileges for Authz Decision
Web
Login
Server
HS
Authentication
Authorization
Success!
Phase
WAYF
Target
Web
Server
Ask For Privileges
Second Access - Authenticated
Browser
Pass content
if user
is allowed
Redirect
User to
Campus
for Authn
First Access - Unauthenticated
Origin Site
Target Site
78
IDENTITY PROVIDER(IDP)
IdP allows the user to authenticate stores
information about the user as attributes.
 When a user authenticates, the IdP creates a
privacy-preserving handle for the user which can
be used by service providers to request user
attributes.

79
SERVICE PROVIDER
Acts as a guardian of a Web resource
User
authenticated
Service Provider
Y
requests attributes from the IdP
makes a decision to grant or deny access to
the resource based on the attribute values
N
redirects the user to
the WAYF service
80
INDEXICAL REFERENCE ESTABLISHER(SHIRE)
SP responsible for context/session establishment.
Session establishment will commonly rely on
traditional techniques.
With no session in place, the SHIRE knows nothing
about the user, so must








Ask directly (SHIRE==WAYF)
Redirect the user to a location that will ask on its behalf
(SHIRE!=WAYF)
The SHIRE accepts and validates an assertion from
a HS.
Associates the incoming handle with the session it
creates.
Passes control to the SHAR.
81
WHERE ARE YOU FROM?
The WAYF service provides the user
with a list of institutions (IdPs) and
allows them to choose at which one
they wish to authenticate.
 Then, the WAYF redirects the user
to the chosen IdP.

82
HANDLE SERVER






Works with AA and local Web ISO system
(authentication) to associate a query handle with
an authenticated browser user and generate a
signed assertion.
Performs its work in response to an Attribute
Query HR.
Triggers local campus authentication system.
Generates a Handle.
Remembers mapping from Handle to specific user.
Sends Assertion with Handle to SHIRE.
83
ATTRIBUTE REQUESTER



Attribute: authenticate stores information
about the user.
A SHAR makes attribute requests using the
handle given it by the SHIRE.
Upon receiving a response (AQR):
 Authenticates the response
 The attribute assertion contains the name
of the origin site.
 Extracts the attributes.
 Checks attribute acceptance.
84
ATTRIBUTE AUTHORITY
Receives Attribute Query Messages (AQM)
from SHAR  Returns Attribute Response
Message (ARM).

•
•


Finds ARPs matching target.
Determines which attributes and values to
release.
Provides UI for specification and
management of Attribute Release Policies
(ARPs).
Works with institutional directories and
databases to aggregate and export attributes
in a controlled fashion.
85
MANAGEMENT OF ATTRIBUTE
RELEASE POLICIES(ARP)

The AA provides ARP management tools/interfaces.
 Different ARPs for different targets.
 Each ARP Specifies: attributes - values.
 Institutional ARPs (default)
 Administrative default policies / attributes.
 Site can force include and exclude.
 User ARPs managed via MyAA web interface.
 Release set determined by combining Default / User
ARP for the specified resource.
86
RESOURCE MANAGER



Accepts Attributes from the SHAR
Compares supplied Attributes against Policy
associated with requested resource
Grants/Denies access
87
ADVANTAGE






End User Authentication
 Unified authentication mechanism, more scalable, less integration work
Access Control
 Ability to implement fine-grained access control by attributes, control
usage costs.
Leading Edge
 Ability to market yourself as being at the fore front of compelling new
technology adoption.
ROI - Vendor
 The incremental cost of adding new customers is relatively minimal.
ROI - Customer
 support inter-institutional applications, leveraging something already in
place.
 A matter of managing attributes/The installation is relatively easy.
Joint Procurement:
 Opportunity to offer joint procurement services
 Providing economies of scale
88
REFERENCES












http://www.w3schools.com/
http://www.xml.com/pub/a/ws/2003/03/04/security.html?page=2
http://xml.coverpages.org/xacml.html
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=xacml#INTEROPS
http://sunxacml.sourceforge.net/
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
http://www.oasis-open.org/committees/download.php/3412/sstc-samldiff-1.1-draft-01.pdf
http://www.oasis-open.org/committees/security
http://projects.staffs.ac.uk/suniwe/project/shibboleth.html
http://middleware.internet2.edu/shibboleth
http://www.internet2.edu/members/html/intellectualproperty.html
89
Q&A
90