T-110.5140 Network Application Frameworks and XML Web Service Security 06.04.2009 Sasu Tarkoma Based on slides by Pekka Nikander.
<ul><li> Slide 1 </li> <li> T-110.5140 Network Application Frameworks and XML Web Service Security 06.04.2009 Sasu Tarkoma Based on slides by Pekka Nikander </li> <li> Slide 2 </li> <li> Contents n Web service security n WS-Security Standard n Security contexts n SAML n XACML n CardSpace n OpenID n Summary </li> <li> Slide 3 </li> <li> Web Services Security Requirements n Protect messaging across domains n Convey security information in messages n Make security decisions and communicate them between parties n Tools at hand u WS-Security, XML-Signature u SAML u XACML u Digital certificate validation u Content-filtering XML F Filters based on data format (XSD) F Filters based on content (XPath) F Filters based on integrity (XML Signature) </li> <li> Slide 4 </li> <li> WS Security I n Web Services Security: SOAP Message Security u 1.0 (Oasis Standard 2004) u 1.1 (Oasis Standard 2006) F Extensions in: security token support, message attachments and rights management. n End-to-End security u Headers are decrypted and processed as needed n Selective processing u Some parts are plain text u Some are encrypted u Some are signed n How does it work? u SOAP header carries security information (and other info as well) </li> <li> Slide 5 </li> <li> WS Security II n Ability to send security tokens as part of a message, message integrity, and message confidentiality n Security model in terms of security tokens combined with digital signatures to protect and authenticate SOAP messages n An X.509 is an example of a signed security token endorsed by a CA. n When third party support is not available, receiver may choose to accept the claims in the token based on trust on the entity that sent the message. </li> <li> Slide 6 </li> <li> Goals n Multiple security token formats n Multiple trust domains n Multiple signature formats n Multiple encryption technologies n Targeted message content security and not just transport-level security </li> <li> Slide 7 </li> <li> Non-goals n Establishing a security context or authentication mechanism n Key derivation n Advertisement and exchange of security policy n How trust is established or determined n Non-repudiation </li> <li> Slide 8 </li> <li> Message Protection n Integrity mechanism designed to support multiple signatures n Uses XML Signature and XML Encryption n Syntax and semantics of signatures within a element u This is the security block in the SOAP header u SOAP actor/role attribute is used to target header blocks n Security element includes u Security tokens u Information about the use of XML Encryption & Signature in the SOAP header/body/combination </li> <li> Slide 9 </li> <li> Security Header n May be present multiple times in a SOAP message u Must have different actor/role attribute values u Unrecognized extension elements or attributes should cause a fault u Receivers MAY ignore elements or extensions within the element, based on local security policy. F But they must understand them first..... </li> <li> Slide 10 </li> <li> Error Handling n SOAP Faults are used to indicate faults n Error scenarios u Security token type unsupported F Note: WS-Policy may be used to convey what security tokens can be understood by different parties F Fault code: InvalidSecurity (if contents of the header block cannot be processed) u Invalid security token F For example: security token corrupted or has invalid signature F Fault code: InvalidSecurityToken u Security token cannot be authenticated F For example: given certificate cannot be validated F Fault code: FailedAuthentication u Security token unavailable F For example: a certificate was referenced that could not be located F Fault code: wsse:SecurityTokenUnavailable </li> <li> Slide 11 </li> <li> Extensions in 1.1 n Builds on 1.0 n WS-Security 1.1 extensions include u EncryptedKeyToken security token F Represents a security token for an encrypted symmetric key. u EncryptedHeader block F Protect any header block, also nested n Digital signature confirmation u A digital signature confirmation is a SOAP message that a Web service sends to a client that confirms that it verified the client's digital signature. </li> <li> Slide 12 </li> <li> Security Contexts in Web Services n Remember Web Services goals: u Re-use existing services u Combine services from several domains n Security result: Must support several security domains u SOAP intermediaries u Reusing security tokens from one message in another message </li> <li> Slide 13 </li> <li> Example 1: Pass subject details Web Browser Website Appl. Server Web Service HTTP POST SOAP Security Context I Security Context II Main Point: We need security within AND between security contexts! </li> <li> Slide 14 </li> <li> Example 2: SOAP Routing SOAP HTTP SOAP SMTP Security Context I Security Context II Main Point: We need XML validation, encryption, and authentication between security contexts! </li> <li> Slide 15 </li> <li> Functional point of view Routing IntegrityValidation Content Checking Authentication Authorization XML Management Console Design and Deploy Security policies ID Management LDAP PKI Single Sign-On Reporting Activity Alerting Secure logging XML </li> <li> Slide 16 </li> <li> Source: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/wssp.asp </li> <li> Slide 17 </li> <li> SAML n SAML (Security Assertion Markup Language) u A XML-based framework (schemas) for the exchange of authentication and authorization information u A standard message exchange protocol F How you ask and receive information n Mainly for integration, up to relying parties to decide to what authentication authority to trust n Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources u Authentication statements merely describe acts of authentication that happened previously n Specified by OASIS </li> <li> Slide 18 </li> <li> SAML in a nutshell n XML-based framework for exchanging security information u XML-encoded security assertions u XML-encoded request/response protocol u Rules on using assertions with standard transport and messaging frameworks n SAML & WS-Security allow a SOAP message to include information about the end-users authentication status </li> <li> Slide 19 </li> <li> SAML Motivation: Portable Trust User Service User Service Domain ADomain B Authentication server A Authentication server A Authentication server B Authentication server B Using services in B from A? Authentication at B? Not acceptable! </li> <li> Slide 20 </li> <li> User Service User Service Domain ADomain B Authentication server A Authentication server A Authentication server B Authentication server B Authentication server C Authentication server C Timed updates </li> <li> Slide 21 </li> <li> SAML assertions n An assertion is a declaration of fact about a subject, e.g. a user u According to some assertion issues n SAML has three kinds, all related to security: u Authentication u Attribute u Authorization decision n You can extend SAML to make you own kinds of assertions n Assertions can be digitally signed </li> <li> Slide 22 </li> <li> All assertions have some common information n Issuer and issuance timestamp n Assertion ID n Subject u Name plus the security domain u Optional subject information, e.g. public key n Conditions under which assertion is valid u SAML clients must reject assertions containing unsupported conditions u Special kind of condition: assertion validity period n Additional advice u E.g. to explain how the assertion was made </li> <li> Slide 23 </li> <li> Authentication assertion n An issuing authority asserts that: u Subject S u was authenticated by means M u at time T n Caution: actually checking or revoking of credentials is not in the scope of SAML! u Password exchange u Challenge-response u Etc. n It merely lets you link back to acts of authentication that took place previously </li> <li> Slide 24 "> </li><li> Example authentication assertion </li> <li> Slide 25 </li> <li> Assertion typeDescription Authentication Assertion Asserts that subject S was authenticated by means M at time T Attribute Assertion Asserts that subject S is associated with attributes A1, A2, with values V1,V2,... Authorization Decision Assertion Should the request to subject S for access type A be granted to resource R given evidence E </li> <li> Slide 26 </li> <li> Overview of SSO Technologies HTTP Liberty ID-FFWS-Federation SAML 1.1WS-Trust WS-Security SOAP SAML 2.0 Shibboleth Integrated with Liberty specifications and the result is SAML 2.0, which OASIS ratified in March 2006. Backed by multiple vendors (IBM, BEA,..) Backed by Microsoft </li> <li> Slide 27 </li> <li> XACML n XACML 2.0 and all the associated profiles were approved as OASIS Standards on 1 February 2005. n XACML defines three top-level policy elements:, and. The u 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 may form the basic unit of management, and be re-used in multiple policies. u The element contains a set of elements and a specified procedure for combining the results of their evaluation. It is the basic unit of policy used by the PDP, and so it is intended to form the basis of an authorization decision. n Defines algorithms arriving at an authorization decision given the input rules and policies </li> <li> Slide 28 </li> <li> 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 should be performed by the PEP in conjunction with the enforcement of authorization decision </li> <li> Slide 29 </li> <li> SAML and XACML PEP Policy Enforcement Point PEP Policy Enforcement Point Web Service PDP Policy Decision Point PDP Policy Decision Point PRP Policy Retrieval Point PRP Policy Retrieval Point PIP Policy Information Point PIP Policy Information Point Policy Store (XACML) Policy Store (XACML) PAP Policy Admin. Point PAP Policy Admin. Point WS request (SOAP) WS request SAML Authrz. decision query Reply 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 Once the SAML authoriz. Has ben made it may be included into the SOAP message and used by the target WS. SOAP msg is Intercepted. SAML query is formed, results determine access. Identity info taken from request. There may be multiple PEPs. </li> <li> Slide 30 </li> <li> Implementations n Trust Services Integration Kit (TSIK), Verisign u Java API for creating trusted services, includes a SAML API u http://www.xmltrustcenter.org/developer/verisign/tsik/inde x.htm n Apache XML-Security, Apache Software Foundation u XML Digital Signature and XML Encryption (Java, C++) u http://xml.apache.org/security/ n Web Services Enhancements 2.0, Microsoft u.NET implementation of various WS Security specs. u http://msdn.microsoft.com/webservices/building/wse/ n Microsoft Passport, Microsoft u Single sign-on support n XML Security Suite, IBM u XML Digital Signature, XML Encryption and XML Access Control Language (Java) u http://www.alphaworks.ibm.com/tech/xmlsecuritysuite n SunONE Identity Server, Sun Microsystems u Supports Libertys federated identity and SAML </li> <li> Slide 31 </li> <li> Web Services Enhancements 3.0 n Implements many of the rules of the WS-* specifications n Works with HTTP and SOAP (SoapExtensions) n Supported specifications u WS-Security, WS-SecurityPolicy, WS- SecureConversation, WS-Trust, WS-Referral, WS- Addressing, WS-Policy, WS-Attachments u 3.0 supports WS-Security 1.1 n Supports signing/encrypting message elements and policies n Overview u http://msdn.microsoft.com/library/default.asp?url=/li brary/en-us/dnwse/html/newwse3.asp </li> <li> Slide 32 </li> <li> WSE turnkey security profiles n Common scenarios/patterns for securing messaging u UsernameOverTransport (username+pass&SSL) u UsernameForCertificate (username+pass&X.509 server auth) u AnonymousForCertificate(X.509 server auth) u MutualCertificate10 (X.509 client&server auth WS- S 1.0) u MutualCertificate11 (X.509 client&server auth WS- S 1.1) u Kerberos (Windows) n Implemented using policy files n Tokens and web farms u http://msdn.microsoft.com/library/default.asp?url=/li brary/en-us/dnwebsrv/html/sctinfarm.asp </li> <li> Slide 33 Note that both the client and server need to share part of the profile."> </li><li> Note that both the client and server need to share part of the profile. </li> <li> Slide 34 </li> <li> Passport and Live ID n Intended to solve two problems u to be an identity provider to MSN u identity provider for the Internet n First goal u over 250 million active Passport accounts and u 1 billion authentications per day n Second goal u What is the role of the identity provider in transactions? u Passport no longer stores personal information other than username/password credentials n Authentication service for sites n Proprietary technology n Roadmap: towards identity card (CardSpace) u Interface for identity based authentication and authorization u Identity cards that people can choose (Identity Metasystem) u Integration with Web sites u Consistent user interface n Windows Live ID u Unified login service for Microsoft sites such as Hotmail, MSNBC, MSN,.. u Used also for ad targeting with adCenter u Has been opened for Web site developers (August, 2007) </li> <li> Slide 35 </li> <li> Identities n CardSpace (Microsoft) u Multiple identities u Interface for identity based authentication and authorization u Identity cards that people can choose u Integration with Web sites u Consistent user interface u Microsoft plans to implement this F ActiveX, WS-* n http://www.identityblog.com/ </li> <li> Slide 36 </li> <li> IdentityCard Source: http://www.identityblog.com/ </li> <li> Slide 37 </li> <li> OpenID n OpenID is a decentralized sign-on system for the Web u Not a real single sign-on solution, does not support authorization n Instead of usernames and passwords, users need to have an account with some identity provider n The user has the choice of selecting a suitable identity provider n Support: AOL, Orange, FireFox, Microsoft planning support in Vista, LiveJournal, Wikitravel, Zooomr, Ma.gnolia n Estimated 120 million OpenIDs on the Internet n OpenID 2.0 supports discovery u Yadis provides a mechanism for determining the services that are available with a given identifier n Identity aggregation: ClaimID u Claim Web resources under your OpenID (must have write permission) </li> <li> Slide 38 </li> <li> Open...</li></ul>