Web Services XML WS Security Architectures
Transcript of Web Services XML WS Security Architectures
-
8/8/2019 Web Services XML WS Security Architectures
1/69
-
8/8/2019 Web Services XML WS Security Architectures
2/69
Web Services Basics revisitedWeb service securityWS-Security Standard
Security contexts SAMLXACMLCardSpaceOpenID Summary
-
8/8/2019 Web Services XML WS Security Architectures
3/69
-
8/8/2019 Web Services XML WS Security Architectures
4/69
1. Why Web Services?
2. The Web Services Computing Stack.
3. Summary.
-
8/8/2019 Web Services XML WS Security Architectures
5/69
Livermore July 25 2001
-
8/8/2019 Web Services XML WS Security Architectures
6/69
Web designed for application to human interactions Served very well its purpose:
Information sharing: a distributed content library. Enabled B2C e-commerce.
Non-automated B2B interactions.
How did it happen? Built on very few standards: http + html
Shallow interaction model: very few assumptions made
about computing platforms. Result was ubiquity.
-
8/8/2019 Web Services XML WS Security Architectures
7/69
The Web is everywhere. There is a lot more we can do! E-marketplaces. Open, automated B2B e-commerce.
Business process integration on the Web.
Resource sharing, distributed computing.
Current approach is ad-hoc on top of existing standards. e.g., application-to-application interactions with HTML forms.
Goal:
enabling systematic application-to-applicationinteraction on the Web.
-
8/8/2019 Web Services XML WS Security Architectures
8/69
Web services is an effort to build adistributed computing platform for the
Web.
Yet another one!
-
8/8/2019 Web Services XML WS Security Architectures
9/69
Goals Enable universal interoperability.Widespread adoption, ubiquity: fast!
Compare with the good but still limited adoption of theOMGs OMA.
Enable (Internet scale) dynamic binding. Support a service oriented architecture (SOA).
Efficiently support both open (Web) and more
constrained environments.
-
8/8/2019 Web Services XML WS Security Architectures
10/69
Requirements Based on standards. Pervasive support is critical.
Minimal amount of required infrastructure isassumed.Only a minimal set of standards must be implemented.
Very low level of application integration isexpected.But may be increased in a flexible way.
Focuses on messages and documents, not onAPIs.
-
8/8/2019 Web Services XML WS Security Architectures
11/69
Web service applications areencapsulated, loosely coupledWeb components that canbind dynamically to each other
-
8/8/2019 Web Services XML WS Security Architectures
12/69
-
8/8/2019 Web Services XML WS Security Architectures
13/69
Framework can be described in terms of
What goes on the wire:
Formats and protocols.
What describes what goes on the wire:
Description languages.
What allows us to find these descriptions:
Discovery of services.
-
8/8/2019 Web Services XML WS Security Architectures
14/69
SOAP 1.1 defined: An XML envelope for XML messaging,
Headers + body
An HTTP binding for SOAP messaging. SOAP is transport independent.
A convention for doing RPC. An XML serialization format for structured data
SOAP Attachments addsHow to carry and reference data attachments
using in a MIME envelope and a SOAP envelope.
-
8/8/2019 Web Services XML WS Security Architectures
15/69
< SOAP-ENV:Header>
...
< SOAP-ENV:Body>
...
...
-
8/8/2019 Web Services XML WS Security Architectures
16/69
Internet-scale integration needsa lingua-franca
XML messaging protocolover HTTP: SOAP
Intra-enterprise integrationneeds to allow alternates:
CORBA, RMI
Messaging
In-memory method calls
SOAPSOAP
SecuritySecurity
AttachmentsAttachments
ReliabilityReliability
RoutingRouting
TransactionsTransactions
ContextContext
W3C
-
8/8/2019 Web Services XML WS Security Architectures
17/69
Integration requiresinteroperable machine-
understandable descriptions
Enables dynamic, delayedbinding of components.
Language extensibility
provides support for differentlevels of applicationintegration.
InterfaceInterface
Service QoSService QoS
ServiceService
Public FlowsPublic Flows
Flows andCompositionFlows and
Composition
AgreementsAgreements
WSDL
WSFL
XML SchemaXML Schema
-
8/8/2019 Web Services XML WS Security Architectures
18/69
Provides functional description of network services: IDL description
Protocol and deployment details
Platform independent description.
Extensible language. A short history:
WSDL v1.0, 9/2000
WSDL v1.1 submitted to W3C 3/2001.
A de facto industry standard.
-
8/8/2019 Web Services XML WS Security Architectures
19/69
portType Abstract definition of a
service (set ofoperations)
Multiple bindings perportType: How to access it
SOAP, JMS, direct call
Ports Where to access it
Service
Port(e.g. http://host/svc)
Binding(e.g. SOAP)
Abstract interface
portType
operation(s)
inMesage outMessage
Port
Binding
-
8/8/2019 Web Services XML WS Security Architectures
20/69
1. As extended IDL: WSDL allows tools to generatecompatible client and server stubs. Tool support for top-down, bottom-up and meet in the
middle development.
1.
Allows industries to define standardized serviceinterfaces.
2. Allows advertisement of service descriptions,enables dynamic discovery and binding ofcompatible services.
Used in conjunction with UDDI registry1. Provides a normalized description of
heterogeneous applications.
-
8/8/2019 Web Services XML WS Security Architectures
21/69
Client Proxy
object
RMI-
IIOP
JMS/
MQ
SOAP/
HTTP
Single stub can invoke services over different bindings Depends only on abstract interface.
Are independent of binding (but pluggable).
Add new bindings without recompiling/redeployingstub
Allows optimisations
based on the bindings of service.
Will support extended
services models if described
In WSDL
-
8/8/2019 Web Services XML WS Security Architectures
22/69
WSFL describes WebService compositions.
1.Usage patterns of Web
Services: describesworkflow or businessprocesses.
2. Interaction patterns:describes overall partnerinteractions.
A
B
C
[ WS]
[ WS]
-
8/8/2019 Web Services XML WS Security Architectures
23/69
Activitiesrepresent
units ofprocessing.
Flow of data ismodeledthrough datalinks.
[ WS]
Activities can bemapped to theflow interface
Control links defineexecution flow as a
directed acyclic graphActivities areassociated withspecific typedservice providers
-
8/8/2019 Web Services XML WS Security Architectures
24/69
Public flows provide a representation of the service behavioras required by its users. Typically, an abstraction of the actual flow begin executed Defines a behavioral contract for the service.
Internal implementation need not be flow-based.
Flows are reusable: specify components types, but not whatspecific services should be used!
Private flows are the flows executed in practice. WSFL serves as a portable flow implementation language
Same language is used in WSFL to represent both types ofprocesses.
-
8/8/2019 Web Services XML WS Security Architectures
25/69
Global models describe how
the composed Web Services
interact.
RosettaNet automated. Like an ADL.
Interactions are modeled as
links between endpoints of
two service interfaces (WSDLoperations).
An essentially distributed
description of the interaction.
A
B
C
-
8/8/2019 Web Services XML WS Security Architectures
26/69
Static bindingrequires servicelibraries.
Dynamic bindingrequires runtimediscovery of meta-data InspectionInspection
DirectoryDirectory
ADS,DISCO
UDDI
-
8/8/2019 Web Services XML WS Security Architectures
27/69
UDDI defines the operation of a serviceregistry: Data structures for registering
BusinessesTechnical specifications: tModel is a keyed reference to a
technical specification. Service and service endpoints: referencing the supported
tModels
SOAP Access API Rules for the operation of a global registry
private UDDI nodes are likely to appear, though.
-
8/8/2019 Web Services XML WS Security Architectures
28/69
Web Service
Web Service
SIC CODENAICS
DUNS NumbersThomas Registry ID
Rosetta-NetBASDASimple.Buy
Schemas,
Interchange specification
businessEntitybusinessEntitybusinessEntity
businessServicebusinessService
bindingTemplatebindingTemplate
InstanceDetailsInstanceDetails
categoryBagkeyedReferencekeyedReference
identifierBag
keyedReferencekeyedReference
tModels
-
8/8/2019 Web Services XML WS Security Architectures
29/69
-
8/8/2019 Web Services XML WS Security Architectures
30/69
The Web services framework is being defined,standardized and supported by the industry at arecord pace.
Broad industry acceptance and standard compliancewill make it ubiquitous.
Will bring an unprecedented level of interoperabilityto Web applications.
The benefits of Web services, however, are notlimited to the Web!
-
8/8/2019 Web Services XML WS Security Architectures
31/69
-
8/8/2019 Web Services XML WS Security Architectures
32/69
-
8/8/2019 Web Services XML WS Security Architectures
33/69
Web Services Security: SOAP Message Security 1.0 (Oasis Standard 2004) 1.1 (Oasis Standard 2006)
Extensions in: security token support, message attachments and rightsmanagement.
End-to-End security Headers are decrypted and processed as needed
Selective processing Some parts are plain text Some are encrypted Some are signed
How does it work? SOAP header carries security information (and other info as well)
-
8/8/2019 Web Services XML WS Security Architectures
34/69
Ability to send security tokens as part of a message,message integrity, and message confidentiality
Security model in terms of security tokens combined withdigital signatures to protect and authenticate SOAP
messages An X.509 is an example of a signed security token
endorsed by a CA.
When third party support is not available, receiver maychoose to accept the claims in the token based on trust
on the entity that sent the message.
-
8/8/2019 Web Services XML WS Security Architectures
35/69
Multiple security token formatsMultiple trust domains
Multiple signature formats
Multiple encryption technologies
Targeted message content security andnot just transport-level security
-
8/8/2019 Web Services XML WS Security Architectures
36/69
Establishing a security context orauthentication mechanism
Key derivation
Advertisement and exchange ofsecurity policy
How trust is established or determined
Non-repudiation
-
8/8/2019 Web Services XML WS Security Architectures
37/69
Integrity mechanism designed to support multiple signatures Uses XML Signature and XML Encryption
Syntax and semantics of signatures within a element This is the security block in the SOAP header
SOAP actor/role attribute is used to target header blocks
Security element includes Security tokens
Information about the use of XML Encryption & Signature in theSOAP header/body/combination
-
8/8/2019 Web Services XML WS Security Architectures
38/69
May be present multiple times in a SOAP message Must have different actor/role attribute values
Unrecognized extension elements or attributesshould cause a fault
Receivers MAY ignore elements or extensionswithin the element, based onlocal security policy. But they must understand them first
..
...
-
8/8/2019 Web Services XML WS Security Architectures
39/69
SOAP Faults are used to indicate faults Error scenarios
Security token type unsupported Note: WS-Policy may be used to convey what security tokens can be understood
by different parties Fault code: InvalidSecurity (if contents of the header block cannot be processed)
Invalid security token For example: security token corrupted or has invalid signature Fault code: InvalidSecurityToken
Security token cannot be authenticated For example: given certificate cannot be validated Fault code: FailedAuthentication
Security token unavailable For example: a certificate was referenced that could not be located
Fault code: wsse:SecurityTokenUnavailable
-
8/8/2019 Web Services XML WS Security Architectures
40/69
Builds on 1.0WS-Security 1.1 extensions include
EncryptedKeyToken security token Represents a security token for an encrypted symmetric
key. EncryptedHeader block Protect any header block, also nested
Digital signature confirmationA digital signature confirmation is a SOAP message
that a Web service sends to a client that confirmsthat it verified the client's digital signature.
-
8/8/2019 Web Services XML WS Security Architectures
41/69
Remember Web Services goals: Re-use existing servicesCombine services from several domains
Security result: Must support severalsecurity domainsSOAP intermediaries
Reusing security tokens from one messagein another message
-
8/8/2019 Web Services XML WS Security Architectures
42/69
Web
BrowserWebsite
Appl.
Server
Web
Service
HTTP POST SOAP
Security Context I
Security Context II
Main Point: We need security within AND
between security contexts!
-
8/8/2019 Web Services XML WS Security Architectures
43/69
SOAP HTTP SOAP SMTP
Security Context I
Security Context II
Main Point: We need XML validation,
encryption, and authentication between
security contexts!
-
8/8/2019 Web Services XML WS Security Architectures
44/69
Routing
Integrity Validation
Content Checking
AuthenticationAuthorization
XML
ManagementConsole
Design and
Deploy
Security
policies
ID Management
LDAP
PKISingle Sign-On
Reporting
ActivityAlerting
Secure loggingXML
-
8/8/2019 Web Services XML WS Security Architectures
45/69
Source: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/wssp.asp
-
8/8/2019 Web Services XML WS Security Architectures
46/69
SAML (Security Assertion Markup Language) A XML-based framework (schemas) for the
exchange of authentication and authorizationinformation
A standard message exchange protocol How you ask and receive information
Mainly for integration, up to relying parties todecide to what authentication authority to trust
Assertions can convey information aboutauthentication acts performed by subjects,attributes of subjects, and authorizationdecisions about whether subjects are allowed toaccess certain resources Authentication statements merely describe
acts of authentication that happenedpreviously Specified by OASIS
-
8/8/2019 Web Services XML WS Security Architectures
47/69
XML-based framework for exchangingsecurity information XML-encoded security assertionsXML-encoded request/response protocolRules on using assertions with standard
transport and messaging frameworks SAML & WS-Security allow a SOAP message to
include information about the end-usersauthentication status
-
8/8/2019 Web Services XML WS Security Architectures
48/69
User
Service
User
Service
Domain A Domain B
Authenticationserver A
Authenticationserver B
Using services in B from A?
Authentication at B?
Not acceptable!
Domain A Domain B
-
8/8/2019 Web Services XML WS Security Architectures
49/69
Authentication
server C
Timed
updates
Timed
updates
User
Service
User
Service
Authentication
server A
Authentication
server B
-
8/8/2019 Web Services XML WS Security Architectures
50/69
An assertion is a declaration of fact abouta subject, e.g. a user According to some assertion issues
SAML has three kinds, all related tosecurity:AuthenticationAttributeAuthorization decision
You can extend SAML to make you ownkinds of assertions
Assertions can be digitally signed
-
8/8/2019 Web Services XML WS Security Architectures
51/69
Issuer and issuance timestamp Assertion ID
Subject Name plus the security domain Optional subject information, e.g. public key
Conditions under which assertion is valid SAML clients must reject assertions containing unsupported
conditions
Special kind of condition: assertion validity period
Additional advice E.g. to explain how the assertion was made
-
8/8/2019 Web Services XML WS Security Architectures
52/69
An issuing authority asserts that:Subject Swas authenticated by means Mat time T
Caution: actually checking or revoking ofcredentials is not in the scope of SAML!Password exchangeChallenge-responseEtc.
It merely lets you link back to acts ofauthentication that took place previously
-
8/8/2019 Web Services XML WS Security Architectures
53/69
-
8/8/2019 Web Services XML WS Security Architectures
54/69
Assertion type Description
Authentication Assertion Asserts that subject S wasauthenticated by means M at time T
Attribute Assertion Asserts that subject S is associatedwith attributes A1, A2, with valuesV1,V2,...
Authorization DecisionAssertion
Should the request to subject S foraccess type A be granted toresource R given evidence E
-
8/8/2019 Web Services XML WS Security Architectures
55/69
HTTP
Liberty ID-FF WS-Federation
SAML 1.1 WS-Trust
WS-Security
SOAP
SAML 2.0
Shibboleth
Integrated with Liberty specificationsand the result is SAML 2.0, whichOASIS ratified in March 2006. Backed
by multiple vendors (IBM, BEA, ..)
Backed by Microsoft
-
8/8/2019 Web Services XML WS Security Architectures
56/69
XACML 2.0 and all the associated profiles were approved as OASISStandards on 1 February 2005.
XACML defines three top-level policy elements: , and. The element contains a Boolean expression that can be evaluated in
isolation, but that is not intended to be accessed in isolation by a PDP. So,it is not intended to form the basis of an authorization decision by itself.
It is intended to exist in isolation only within an XACML PAP, where it mayform the basic unit of management, and be re-used in multiplepolicies. The element contains a set of elements and a specified
procedure for combining the results of their evaluation. It is the basic unit ofpolicyused by the PDP, and so it is intended to form the basis of anauthorization decision.
Defines algorithms arriving at an authorization decision given theinput rules and policies
-
8/8/2019 Web Services XML WS Security Architectures
57/69
Source: http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf
Permit or
deny
Boolean
expression
An operation that shouldbe performed by the
PEP in conjunction with
the enforcement of
authorization decision
Once the SAML authoriz. Has ben madeSOAP msg is
Intercepted SAML query is formed results
-
8/8/2019 Web Services XML WS Security Architectures
58/69
PEP
Policy Enforcement Point Web Service
PDP
Policy Decision Point
PRP
Policy Retrieval Point
PIP
Policy Information Point
Policy Store
(XACML)
PAP
Policy Admin. Point
WS request (SOAP) WS request
SAML Authrz. decision
queryReply
XACML Policy request
Policy (XACML)
Info request
Attribute assertion
Rules are combined:
subjects, resources,
and attributes.
Exported into XACML.
PDP queries attributes
from PIP (time of day,
value, etc.). PIP returns
an attribute assertion.
Once the PDP has all the
relevant information, it evaluates
rules and returns a SAML
authoriz. Assertion
it may be included into the SOAP
message and used by the target WS.
Intercepted. SAML query is formed, results
determine access. Identity info taken from
request. There may be multiple PEPs.
-
8/8/2019 Web Services XML WS Security Architectures
59/69
Trust Services Integration Kit (TSIK), Verisign Java API for creating trusted services, includes a SAML API http://www.xmltrustcenter.org/developer/verisign/tsik/index.htm
Apache XML-Security, Apache Software Foundation XML Digital Signature and XML Encryption (Java, C++) http://xml.apache.org/security/
Web Services Enhancements 2.0, Microsoft .NET implementation of various WS Security specs. http://msdn.microsoft.com/webservices/building/wse/
Microsoft Passport, Microsoft Single sign-on support
XML Security Suite, IBM XML Digital Signature, XML Encryption and XML Access Control Language
(Java) http://www.alphaworks.ibm.com/tech/xmlsecuritysuite
SunONE Identity Server, Sun Microsystems Supports Libertys federated identity and SAML
-
8/8/2019 Web Services XML WS Security Architectures
60/69
Implements many of the rules of the WS-* specifications Works with HTTP and SOAP (SoapExtensions) Supported specifications
WS-Security, WS-SecurityPolicy, WS-SecureConversation, WS-Trust,WS-Referral, WS-Addressing, WS-Policy, WS-Attachments
3.0 supports WS-Security 1.1 Supports signing/encrypting message elements and policies Overview
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/newwse3.asp
-
8/8/2019 Web Services XML WS Security Architectures
61/69
Common scenarios/patterns for securing messaging UsernameOverTransport (username+pass&SSL) UsernameForCertificate (username+pass&X.509 server auth) AnonymousForCertificate(X.509 server auth) MutualCertificate10 (X.509 client&server auth WS-S 1.0) MutualCertificate11 (X.509 client&server auth WS-S 1.1) Kerberos (Windows)
Implemented using policy files Tokens and web farms
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/sctinfarm.asp
-
8/8/2019 Web Services XML WS Security Architectures
62/69
Note that both the client and server need to share part of the profile.
-
8/8/2019 Web Services XML WS Security Architectures
63/69
Intended to solve two problems to be an identity provider to MSN identity provider for the Internet
First goal over 250 million active Passport accounts and 1 billion authentications per day
Second goal What is the role of the identity provider in transactions? Passport no longer stores personal information other than
username/password credentials Authentication service for sites Proprietary technology Roadmap: towards identity card (CardSpace)
Interface for identity based authentication and authorization Identity cards that people can choose (Identity Metasystem) Integration with Web sites Consistent user interface
Windows Live ID Unified login service for Microsoft sites such as Hotmail, MSNBC,
MSN, .. Used also for ad targeting with adCenter Has been opened for Web site developers (August, 2007)
-
8/8/2019 Web Services XML WS Security Architectures
64/69
CardSpace (Microsoft) Multiple identities Interface for identity based authentication and
authorization Identity cards that people can choose Integration with Web sitesConsistent user interfaceMicrosoft plans to implement this
ActiveX, WS-* http://www.identityblog.com/
-
8/8/2019 Web Services XML WS Security Architectures
65/69
Source: http://www.identityblog.com/
-
8/8/2019 Web Services XML WS Security Architectures
66/69
OpenID is a decentralized sign-on system for the Web Not a real single sign-on solution, does not support authorization
Instead of usernames and passwords, users need to have anaccount with some identity provider
The user has the choice of selecting a suitable identityprovider
Support: AOL, Orange, FireFox, Microsoft planning support in
Vista, LiveJournal, Wikitravel, Zooomr, Ma.gnolia Estimated 120 million OpenIDs on the Internet
OpenID 2.0 supports discovery
Yadis provides a mechanism for determining the services that
are available with a given identifier
Identity aggregation: ClaimID Claim Web resources under your OpenID (must have write
permission)
-
8/8/2019 Web Services XML WS Security Architectures
67/69
There are two ways to obtain an OpenID-enabledURL that can be used to login on all OpenID-enabled websites. To use an existing URL that one's own control (such as
one's blog or home page), and if one knows how to editHTML, one can insert the appropriate OpenID tags in the
HTML code following instructions at the OpenIDspecification.
The second option is to register an OpenID identifier withan identity provider. They offer the ability to register aURL (typically a third-level domain) that will automaticallybe configured with OpenID authentication service.
End User Relying Party(Site) OpenID Provider
-
8/8/2019 Web Services XML WS Security Architectures
68/69
End User Relying Party(Site) OpenID Provider
Visits
OpenID login page
Login using OpenID
Normalization, d iscovery
Association (optional)
Handle
Request authenticationHTTP/Form Redirect
Potential userinteraction
Auth. response
Ver if res onseUser is authenticated
-
8/8/2019 Web Services XML WS Security Architectures
69/69