1 / 25

WSRP v2 leveraging WS-Security?

WSRP v2 leveraging WS-Security?. Motivation WS-Securtiy Roadmap and Status WSRP Use Cases Strawman/Issues. Motivation. WSRP Interfaces SC has identified and prioritized WSRP security related uses cases

gracie
Télécharger la présentation

WSRP v2 leveraging WS-Security?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WSRP v2 leveraging WS-Security? Motivation WS-Securtiy Roadmap and Status WSRP Use Cases Strawman/Issues WSRP Technical Committee

  2. 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 • 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 • 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 WSRP Technical Committee

  3. WS-SecureConversation WS-Federation WS-Authorization Federation Layer WS-Trust WS-Privacy WS-Policy Policy Layer WS-PolicyFramework WS-PolicyAttachments WS-PolicyAssertions WS-Security SOAP Foundation WS-Security Road Map Today Time WSRP Technical Committee

  4. 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, 6th April 2004 • Vendors issuing statements about supporting WS-Security • Examples: Apache WSS4J, BEA, IBM, Microsoft, Oracle, and Verisign WSRP Technical Committee

  5. 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 WSRP Technical Committee

  6. 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 WSRP Technical Committee

  7. 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 WSRP Technical Committee

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

  9. 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 WSRP Technical Committee

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

  11. 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 WSRP Technical Committee

  12. 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? • 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? WSRP Technical Committee

  13. 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 WSRP Technical Committee

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

  15. 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 WSRP Technical Committee

  16. 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 WSRP Technical Committee

  17. 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 WSRP Technical Committee

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

  19. 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 WSRP Technical Committee

  20. 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 WSRP Technical Committee

  21. 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 WSRP Technical Committee

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

  23. 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 WSRP Technical Committee

  24. 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 WSRP Technical Committee

  25. 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)? • 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 WSRP Technical Committee

More Related