1. August 3, 2004WSRP Technical Committee WSRP v2 leveraging WS-Security 1. Motivation 2. WS-Securtiy Roadmap and Status 3. WSRP Use Cases 4. Strawman/Issues

2. August 3, 2004WSRP Technical Committee Motivation  WSRP Interfaces SC has identified and prioritized WSRP security related uses cases Uses cases are described here: http://www.oasis-open.org/apps/org/workgroup/wsrp- interfaces/download.php/7786/Security-Feature-draft04.html http://www.oasis-open.org/apps/org/workgroup/wsrp- interfaces/download.php/7786/Security-Feature-draft04.html  An overview of the standards and their purpose has been given at the interfaces call Presentation can be found here: http://www.oasis-open.org/apps/org/workgroup/wsrp- interfaces/download.php/6936/Security-Standards-Overview.ppt http://www.oasis-open.org/apps/org/workgroup/wsrp- interfaces/download.php/6936/Security-Standards-Overview.ppt  The WSRP TC has decided to explore how the WS-Security stack can be leveraged to solve the WSRP security requirements identified. Goals are: Identify the WS-Security candidate technologies to solve our use cases Figure out the status of these and try to understand the level of support by various platforms/vendors Provide a first strawman to address our priority 1 use cases and validate the proposed approach Identify open issues/question and probably missing parts

3. August 3, 2004WSRP Technical Committee WS-Security Road Map SOAP Foundation WS-Security WS-SecureConversation WS-TrustWS-Privacy WS-Policy WS-PolicyFramework WS-PolicyAttachmentsWS-PolicyAssertions WS-AuthorizationWS-Federation Policy Layer Federation Layer Today Time

4. August 3, 2004WSRP Technical Committee WS-Security Summary and Status  Describes SOAP header enhancements to provide message integrity and confidentiality By leveraging XML Signature and XML Encryption  Provides general purpose mechanism to attach security tokens to messages No specific type of security token mandated Support for multiple security token formats Provides token profiles for –Plain text tokens (Username, Username/Password) (standardized) –Binary tokens  X.509 certificates (standardized)  Kerberos tickets (working draft) –XML tokens  SAML assertions (working draft)  XrML  V1.0 OASIS Standard, 6 th April 2004  Vendors issuing statements about supporting WS-Security Examples: Apache WSS4J, BEA, IBM, Microsoft, Oracle, and Verisign

5. August 3, 2004WSRP Technical Committee WS-Policy Summary and Status  WS-Policy Grammar for Web service provides to communicate their requirements and capabilities so a Web Service requester can discover the information they need to access the service.  WS-PolicyAttachment Mechanisms to attach these policy statements to a web service. –WSDL –UDDI –Arbitrary resources independent of their definition  Policy Languages WS-PolicyAssertions: –General policies that can be associated with a service (text encoding, language, specVersion, messagePredicate) WS-SecurityPolicy –General security policies that can be associated with a service  Common to all V1.1 public draft, 28 May 2003 Not at a Standards Body yet, but assumed to happen soon Finalization: ??? W3C Web Services Policy Workshop will take place October 12th-13th, 2004

6. August 3, 2004WSRP Technical Committee WSRP Use Cases  We basically identified the “user centric” use cases as the most important ones Especially use cases 3.x were prioritized 1 –All of them deal with the propagation of the user identity Use case 5 deals with assertions/claims like user roles  “Portlet specific” use cases Use case 6: confidentiality of messages exchanged between Consumer and Producer (thus also between user-agent and Consumer) Use case 7: extends 6, runtime based decision if encryption is needed or not Both can be already served using our transport layer security definition of secure URLs (URLtype’s isSecure attribute in case of rewriting, otherwise template usage), however we want to explore message level security here

7. August 3, 2004WSRP Technical Committee Use Case 3.1 - Userid Propagation Within Same Security Domain  Consumer & Producer share the same user registry, i.e. same security domain  Producer requires the authenticated userid to be passed Consumer authenticates the user logging in to the Consumer Consumer passes the user identity to the Producer with all user-related calls (where userContext is passed) Consumer needs to authenticate itself to the Producer Producer trusts Consumer (which authenticated itself) Producer establishes security context using the passed userid If Consumer authentication fails, the message is rejected If userid is unknown, the message is rejected

8. August 3, 2004WSRP Technical Committee 3.1 Strawman - leveraging WS-Security, simple approach ConsumerProducer SOAP HEADER SOAP BODY UserName Token SOAP HEADER SOAP BODY Request Data Response Data 1. Own Cert 2. Root Cert of Producer’s Cert Authority 1. Own Cert 2. Root Cert of Consumer’s Cert Authority User DB

9. August 3, 2004WSRP Technical Committee 3.1 Strawman – simple approach  WS-Security to transport user identity Username token XML token, i.e. SAML assertion BinaryToken, e.g. X.509 certificate  “trust by social contract” Not a real security solution May satisfy some intranet scenarios  Trust could be established using SSL Client certificates to authenticate consumers Encryption to protect messages

10. August 3, 2004WSRP Technical Committee 3.1 Strawman - leveraging WS-Security ConsumerProducer SOAP HEADER SOAP BODY UserName TokenTimeStampX.509 Certificate SOAP HEADER SOAP BODY X.509 Certificate Request Data Response Data 1. Own Cert 2. Root Cert of Producer’s Cert Authority XML Digital Signature 1. Own Cert 2. Root Cert of Consumer’s Cert Authority XML Encryption User DB

11. August 3, 2004WSRP Technical Committee 3.1 Strawman  Request Username token contains shared userid –Signed by Consumer, Producer decides whether or not to trust the asserted userid –Optionally encrypted TimeStamp token to protect against replay, signed to maintain integrity Consumer’s X.509 certificate passed as BinaryToken to identify Consumer, pick up the correct root cert authority and authenticate Consumer Request (message body) signed for message integrity, optionally encrypted  Response Producer’s X.509 certificate as BinaryToken to identify Producer, pick up root cert authority Response in message body signed for message integrity  Message confidentiality XML encryption Alternative: use SSL encryption

12. August 3, 2004WSRP Technical Committee 3.1 Strawman – Issues  WS-Security can be used to propagate the userid Along with XML-Dsig and XML-Enc we can fully protect the messages All we need is already standardized  Could use also other types of tokens for userid propagation, e.g. SAML-Assertion, X.509 binaryTokens  How can Producer express its security requirements? WS-Policy: Defines a meta-language to express requirements in general WS-SecurityPolicy: Express security related requirements (token requirements, integrity & confidentiality requirements, algorithms, etc.) Is our own metadata an option? Do we need such detailed policies at all? I.e. have only a pointer to “WSRP Security Profile”  How can policies be attached? Requirements/Policies need to be per Portlet Need to be able to attach policies to: –Our metadata, i.e. Service/PortletDescription as the primary source? –WSDL (if we describe Portlets in WSDL) or Resource (if we leverage WSRF) ? –Registries, e.g. attach policies to our UDDI Portlet entities?  How is the PKI set up? Probably out-of-band? WS-Trust, to enable trust management?

13. August 3, 2004WSRP Technical Committee Use Case 3.2 – Consumer Acting As Credential Store  Consumer and Producer do not share same user registry  Producer requires Consumer to provide user credentials Consumer authenticates user and keeps credentials of the end- user’s behalf Consumer picks up credentials of targeted Producer and sends them with the user-related requests Producer verifies user credentials and establishes security context If user can not be authenticated message is rejected Optionally, requests from authenticated Consumers only can be accepted

14. August 3, 2004WSRP Technical Committee 3.2 Strawman - leveraging WS-Security ConsumerProducer SOAP HEADER SOAP BODY UserName/PW Token TimeStamp SOAP HEADER SOAP BODY Request Data Response Data 1. Own Cert 2. Root Cert of Producer’s Cert Authority 3. User credentials XML Digital Signature 1. Own Cert 2. Root Cert of Consumer’s Cert Authority 3. User DB XML Encryption X.509 Certificate

15. August 3, 2004WSRP Technical Committee 3.2 Strawman  Request Username token contains userid/password –Optionally signed by Consumer, Producer decides whether or not to accept the userid from that particular Consumer –encrypted TimeStamp token to protect against replay attacks, optionally signed by Consumer to keep integrity Request (message body) optionally signed to keep message integrity, optionally encrypted  Response Response (message body) signed to keep message integrity Optionally encrypted  Message confidentiality XML encryption can be used Alternative: use SSL encryption

16. August 3, 2004WSRP Technical Committee 3.2 Strawman – Issues  WS-Security can be used to propagate the userid/password Along with XML-Dsig and XML-Enc we can fully protect the messages  Could use also other types of tokens for userid propagation, e.g. SAML-Assertion?  How can Producer express its security requirements? (same as #3.1)  How can policies be attached? (same as #3.1)  How is the PKI set up/is it necessary? (same as #3.1)  How does the user subscribe? out-of-band??  How are the credentials provided by Consumer? Credentials per Producer or per Portlet? Once a user interaction requires WSRP request to Producer requiring credentials –Consumer checks credential store if credentials are there –If not Consumer need to indicate/redirect user to the Producer’s subscription mechanism –Do we need some kind of meta-data at the Producer level to provide URL for subscription? –User needs to store these on the Consumer –Once the credentials are stored, the Consumer generates the appropriate Username/PW token  Is this model acceptable from an security point of view at all? Consumer acting as a credential vault, users need to trust the Consumer (probably using SSL server authentication?) Producers/Portlets need to trust the Consumer

17. August 3, 2004WSRP Technical Committee Use Case 3.3 – Producer Maps User Identities  Consumer and Producer do not share the same user registry  Producer requires the Consumer to provide the authenticated user identity Consumer authenticates the user logging in to the Consumer Consumer passes the user identity to the Producer with all user-related calls (where userContext is passed) Consumer needs to authenticate itself to the Producer Producer trusts Consumer (which authenticated itself) Producer maps the passed identity to its own security domain Producer establishes security context based on the mapped id If Consumer authentication fails, the message is rejected If userid is unknown, the message is rejected  Basically the same mechanics of user identity propagation & Consumer authentication as in 3.1 Need to solve user id mapping

18. August 3, 2004WSRP Technical Committee 3.3 Strawman - leveraging WS-Security ConsumerProducer SOAP HEADER SOAP BODY UserName TokenTimeStampX.509 Certificate SOAP HEADER SOAP BODY X.509 Certificate Request Data Response Data 1. Own Cert 2. Root Cert of Producer’s Cert Authority XML Digital Signature 1. Own Cert 2. Root Cert of Consumer’s Cert Authority 3. User mapping XML Encryption

19. August 3, 2004WSRP Technical Committee 3.3 Strawman – Issues  WS-Security can be used to propagate the userid Along with XML-Dsig and XML-Enc we can fully protect the messages  How can Producer express its security requirements? (same as #3.1)  How can policies be attached?  How is the PKI set up?  How can the mapping be established? Producer could redirect the user to login page on first visit (out-of-band) After login, mapping is established and can be used for further interactions Problem: this can only be done on our getMarkup & pbia calls since they are able to return markup/redirects; what about other operations (e.g. clonePortlet which is userContext aware)? Mapping would need to be mapped from Consumer/Userid pair to userid on Producer –Same users targeting the same Producer from different Consumers need to be handled –How can the Consumer preserve uniqueness of user ids over the course of time? –Would require a sign-off operation for when users are deleted/revoked on the Consumer  Is this a valid approach? “lightweight” federation of user ids Could the Producer be viewed as a WS-Trust STS (security token provider) instead? –Consumer checks if interaction to a Producer requires a security token –Consumer requests security token (Producer maps provided user identity of Consumer to some identity at Producer, security token represents this) –Consumer needs to store security token on the end user’s behalf, provides it in follow-on interactions

20. August 3, 2004WSRP Technical Committee 3.3 Strawman – WS-Federation scenario  Consumer could be viewed as identity provider Authenticates the user and asserts an identity Before interacting with the Producer, an access token is requested by the Consumer  Producer can be viewed as security token service Through thrust relationship, the Producer can authenticate the user Do its mapping to a local id Provide an access token  Consumer provides access token on each user-related request

21. August 3, 2004WSRP Technical Committee Use Case 5 – Assertion of User Roles  Producer relies on the asserted user role Consumer authenticates local users and assigns roles to them, roles need to be mapped Consumer provides a role assertion with user-related interactions Consumer needs to authenticate itself to the Producer Producer trusts the Consumer and makes it authorization decisions based on the asserted role

22. August 3, 2004WSRP Technical Committee 5 Strawman - leveraging WS-Security ConsumerProducer SOAP HEADER SOAP BODY XMLToken (SAML)TimeStampX.509 Certificate SOAP HEADER SOAP BODY X.509 Certificate Request Data Response Data 1. Own Cert 2. Root Cert of Producer’s Cert Authority 3. Role mapping XML Digital Signature 1. Own Cert 2. Root Cert of Consumer’s Cert Authority XML Encryption UserName Token ? Could be combined into SAML assertion?

23. August 3, 2004WSRP Technical Committee 5 Strawman  Request XML token contains assertion (e.g. SAML) –Signed by Consumer, Producer can decide whether or not to accept the asserted role from that particular Consumer TimeStamp token to protect against replay attacks, optionally signed by Consumer to keep integrity Request in message body optionally signed to keep message integrity, optionally encrypted  Response Response in message body signed to keep message integrity Optionally encrypted  Message confidentiality XML encryption can be used Alternative: use SSL encryption

24. August 3, 2004WSRP Technical Committee 5 Strawman – Issues  WS-Security can be used to propagate the asserted role Any XML based token could be used, e.g. SAML assertion (*draft from*) Along with XML-Dsig and XML-Enc we can fully protect the messages All we need is already there  Expressing Producer security requirements? (same as #3.1)  How can policies be attached? (same as #3.1)  How is the PKI set up? (same as #3.1)  How can roles be mapped? Producer provides roles and their description –Using WS-Policy? –Or our own metadata? Consumer does the appropriate mapping and asserts Producer-defined roles

25. August 3, 2004WSRP Technical Committee Summary  All basics we need to propagate user ids and role assertion is there WS-Security allows us to transfer any security token XML based tokens can be used to assert roles XML based token could also be used to assert userid  Federating user identities still a hot spot Need to verify our use cases, check which of them make sense WS-Federation provides a model for federating user ids across security domains  Negotiation is an open point How to express requirements? –WS-Policy addresses this –Wait or introduce simple metadata to solve basic requirements (not invent a policy language)? –Is a WSRP Security Profile an option?  Simple trust can be established using PKI Consumer signs headers, to allow Producer to verify the source and validity WS-Trust will help when it comes to token issuance, management of trust Need to bootstrap trust  We can solve our basic requirement by leveraging what is there now No need to invent security related handling within our application-level protocol  However, negotiation is still open Would be also open if we propagated the userid/roles within WSRP protocol WS-Policy is a candidate technology to solve this Need to understand our “negotiation requirements”, i.e. what we want to solve