1 / 46

Seminar on Service Oriented Architecture

Seminar on Service Oriented Architecture. Identification, Authentication and Authorization. Readings on Schedule. See SAML Executive Summary See SAML Technical Overview Read about PubCookie See A SAML Application - Shibboleth. Topics. SAML XACML OpenID. SAML 2.0.

pearldonnell
Download Presentation

Seminar on Service Oriented Architecture

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. Seminar on Service Oriented Architecture Identification, Authentication and Authorization SOA Seminar

  2. Readings on Schedule • See SAML Executive Summary • See SAML Technical Overview • Read about PubCookie • See A SAML Application - Shibboleth SOA Seminar

  3. Topics • SAML • XACML • OpenID SOA Seminar

  4. SAML 2.0 Approved by OASIS, March 2005 Security Assertion Markup Language SOA Seminar

  5. Who Implements SAML 2.0 ? IBM Tivoli Access Manager, Oblix NetPoint, SunONE Identity Server, Baltimore, SelectAccess, Entegrity Solutions AssureAccess, Internet2 OpenSAML, Netegrity SiteMinder, Sigaba Secure Messaging Solutions, RSA Security ClearTrust, VeriSign Trust Integration Toolkit, Entrust GetAccess 7, Microsoft’s Geneva Framework, Oracle SAML An example SAML 2.0 application is Shibboleth. SOA Seminar

  6. SAML Web Service Use Case “SAML is different from other security approaches mostly because of its expression of security in the form of assertions about subjects. Other approaches use a central certificate authority to issue certificates that guarantee secure communication from one point to another within a network. With SAML, any point in the network can assert that it knows the identity of a user or piece of data. It is up to the receiving application to accept if it trusts the assertion. Any SAML-compliant software can assert its authentication of a user or data. This is important for the coming wave of business workflow web services standards where secured data needs to move through several systems for a transaction to be completely processed. “ From IBM Developerworks SOA Seminar

  7. What is Identity Management? “In the information systems security space, identity management recently emerged as a new term that covers the following areas of computing: * Provisioning. Adds new users to network operating system directories and application server directories, both inside an enterprise and outside at partner information systems. * Password management. Enables users to have a single set of credentials to sign on to the company information systems. Additionally, it enables users to self-administer their passwords, user account data, and privileges. * Access control. Enables the system to recognize security policies for groups of users. For example, a security policy would prevent people from changing their own job title and instead route a request for a job title change to the appropriate authority. SAML is a protocol specification to use when two servers need to share authentication information. Nothing in the SAML specification provides the actual authentication service…” From IBM Developerworks SOA Seminar

  8. SAML 2.0 • Security Assertion Markup Language • Organization for the Advancement of • Structured Information Standards • (OASIS) Approved March 2005 • Industry standard way of • representing and exchanging assertions • about identity, attributes and entitlements • Vendor neutral • XML based • Uses SOAP, XMLDSig, XMLEnc • SSL is required between servers SOA Seminar

  9. SAML 2.0 • SAML falls under the broader topic of • Identity Management. • Identity management applies to both network and federated identity. • Federated Identity refers to the use of identity or authorization decisions across organizational boundaries. • Identity management includes the consideration of identity registration, revocation and termination. • SAML’s focus is on single sign on by applications. SOA Seminar

  10. SAML 2.0 Bottom Line • XML encoded security assertions • XML encoded Request/Reply protocol • Rules on how to incorporate these XML constructs in messages SOA Seminar

  11. SAML 2.0 Drivers • Single Sign On Across Domains • Cookies prevent the need for reauthorization • only within the same domain • SSO interoperability (before SAML little) • Web Service Security (SAML allows for the • exchange of assertions within a SOAP • document) • Federated Identity (consolidate identities • across organizational boundaries) • See Shibboleth SOA Seminar

  12. SAML 2.0 Specification Defines(1) • Assertions about: - authentication acts (e.g., YES, the entity did authenticate in this way at this time) - attributes of subjects (e.g., access rights, credit limits, status) name, value pairs - authorization decisions already made Note: Assertions are usually passed from an identity provider to a service provider. Assertions contain statements used by the service provider to make decisions about access control. SOA Seminar

  13. SAML 2.0 Specification Defines(2) • A Simple Request / Reply protocol - Request Types (queries): authentication authorization attribute - One reply format containing assertions. (authentication, authorization or attribute statements) • The requests and replies occur on an SSL channel. The requestor is typically a service provider and the responder an identity provider. SOA Seminar

  14. SAML 2.0 Specification Defines(3) • Bindings How, for example, is SAML carried within a SOAP document? SOAP Message SOAP Header SOAP Body SAML Request or Response SOA Seminar

  15. SAML 2.0 Specification Defines(4) • Profiles - Rules for embedding, extracting and integrating SAML assertions into messages - Error message handling SOA Seminar

  16. SAML 2.0 Request Types • AuthenticationQuery - request any authentication information held by an authority about a subject – has this subject logged in? • AttributeQuery – request attributes of a subject - What is the role associated with this subject? • AuthorizationDecisionQuery – request a decision on subject s to resource r with evidence e. What is your opinion? SOA Seminar

  17. Authentication Query <Request MajorVersion=“1”MinorVersion=“0” RequestID=“128.14.234.20.12345678” IssueInstant=“2001-12-03T10:02:00Z”> <RespondWith>AuthenticationStatement <ds:Signature>…</ds:Signature> <AuthenticationQuery> <Subject> SOA Seminar

  18. Attribute Query <Request…> <AttributeQuery> <Subject>…</Subject> <AttributeDesignator AttributeName=“CreditRating” SOA Seminar

  19. Authorization Decision Query <Request…> <AuthorizationQuery Resource=“http://cmu.edu/salaryFile.htm”> <Subject> <NameIdentifier SecurityDomain=“heinz.cmu.edu” Name=“mike”/> </Subject> <ActionNamespace= “urn:oasis:names:tc:SAML:1.0:action:rwedc”>Read </Action> <Evidence> <Assertion>…</Assertion> </Evidence> </AuthorizationQuery> </Request> SOA Seminar

  20. SAML WS Response SOAP BODY SAML Response Header Assertion Statement Statement SOA Seminar

  21. A SAML WS Response <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="abe567de6" InResponseTo="example-ncname" Version="2.0" IssueInstant="2005-01-31T12:00:00Z" Destination="http://www.example.com/" Consent="http://www.example.com/"> <samlp:Status> <samlp:StatusCode Value="samlp:Success"/> <samlp:StatusMessage>Success</samlp:StatusMessage> <samlp:StatusDetail/> </samlp:Status> …… SAML ASSERTION AND STATEMENTS </samlp:Response> </env:Body> </env:Envelope> SOA Seminar

  22. Assertions <saml:Assertion> <AssertionID> <Issuer> <IssueInstant> <Conditions> <Advice> <Subject> <Authentication Statement> or <Attribute Statement> or <Authorization Statement> Assertions made by a SAML authority. The recipient is normally a service provider. SOA Seminar

  23. Authentication Statement <Assertion> : <AuthenticationStatement> : <ConfirmationMethod> SOA Seminar

  24. Attribute Statement <Assertion> : <AttributeStatement> <Attribute AttrributeName = “PaidStatus” <AttributeValue>PaidUp SOA Seminar

  25. Authorization Decision Statement T decides whether to grant a request by S for access (of a particular type) to resource R given evidence E. SOA Seminar

  26. Authorization Decision Statement <Assertion> : <AuthorizationStatement decision=“permit” resource = “salaryData” action=“read” SOA Seminar

  27. Terminology From SAML Spec • Assertions are declarations of facts about subjects. • The Identity Provider or SAML Authority or Asserting Party is the entity that makes assertions. • The Service Provider or Relying party Relies on information provided by the identity providers. SOA Seminar

  28. Trusted SAML Authority SAML Request SAML Query SAML Response Assertions Relying Party or Service Provider Service Request SOA Seminar

  29. Web SSO Use Case • A web site requires authentication. • The user is transferred to a partner’s web page (both sites are in a “federation”). The partner is a SAML Authority. • The SAML authentication query is passed as well. • If the SAML Authority is satisfied (SAML does not say how) then particular access may be granted and passed (possibly through the browser) to the original web site. • See use case at http://en.wikipedia.org/wiki/SAML. • All of this may be over SSL. SOA Seminar

  30. Business Transaction Use Case • An employee may be authenticated and may qualify to make purchases for her company. • The seller may make inquiries on an authority known by both buyer and seller. • The authority may vouch for the employee and describe her qualifications. SOA Seminar

  31. Authorization Use Case A user attempts to access a resource. The security domain defines a Policy Enforcement Point and a Policy Decision Point. The Policy Enforcement Point makes calls on the Policy Decision Points to check permissions. These calls use SAML on a back channel. SOA Seminar

  32. Lower level Use Cases Pull (Trent manages tokens) (1) Alice authenticates with Trent and receives an 8 byte random token. (2) Alice presents a request for service and the token to Bob. (3) Bob passes the token to Trent and receives assertions about Alice. (4) Bob provides Alice with the service. Assume a back end channel and everything over SSL. SOA Seminar

  33. Lower Level Use Cases • Push (Bob manages tokens) • Alice authenticates with Trent and Trent calls Bob for SAML token (2) Bob responds with token. He knows she is authentic. (3) Trent returns token to Alice. (4) Alice calls Bob with token. (5) Bob provides Alice with service. Bob need not handle authentication and may only provide tokens to Trent. SOA Seminar

  34. XACML 2.0 Approved by OASIS March 2005 XML Access Control Markup Language SOA Seminar

  35. XACML Goals • Industry standard way of representing • and processing access control policies. • Vendor neutral. • XML based. • Provide for “rule combining algorithms”,e.g.,, • “Deny overrides” or “Permit Overrides” • An XACML policy may specify what a • provider should do when it receives a • SAML assertion. SOA Seminar

  36. Who Implements XACML? Oracle BEA SUN Microsoft ? Not yet. IBM SOA Seminar

  37. XACML • Policy Language Used to describe access control requirements. Who is allowed to do what? • Request/Response Language The request is a query about permissions associated with x. The response is permit, deny, indeterminate, or not applicable. SOA Seminar

  38. Drivers • A standard is needed so that policies can be processed and shared • Interoperable • Distributed SOA Seminar

  39. Use Case (1) Policy Enforcement Point (PEP) May I act on some resource? Yes/No Requests and responses defined by XACML Policy Decision Point (PDP) The correct policy in XACML needs to be selected and its rules evaluated. SOA Seminar

  40. Use Case (2) Web Server (PEP) May I read this page Yes <Response> <Result> <Decision>Permit <request> <subject> <resource> <action> Policy Decision Point (PDP) Algorithms for matching requests to policies Policies in XACML <Policy> <Target> <Subjects> <Resources> </Traget> <Rule> <Rule> SOA Seminar

  41. Use Case (3) Web Server (PEP) May I read this page Yes Request may include SAML assertions <Response> <Result> <Decision>Permit Policy Decision Point (PDP) Algorithms for matching requests to policies Policies in XACML <Policy> <Target> <Subjects> <Resources> </Traget> <Rule> SOA Seminar

  42. OpenID • Grassrots effort since 2005 • Web user identification and authentication • OpenID used and provided by: AOL, BBC, Google, IBM, PayPal, Verisign, etc. • Compares a bit with the heavy weight SAML. • In my view, not central to SOA, but worth a look. SOA Seminar

  43. Let’s Give OpenID a drive • A -> B : Service request on B, A’s ID as a URL • B -> C : B Visits URL at C (HTTP Get) • C -> B : HTML Doc holding a pointer to C’s OpenID Server • B -> A : Browser redirect to C’s OpenID Server – many parameters are passed from B to A destined for C – including a nonce SOA Seminar

  44. A -> C : The parameters from B include: mode : checkID_set-up A’s ID as a URL B’s URL, session id and nonce • C authenticates A : OpenID does not dictate how this is done. • C -> A : A browser redirect to B with params destined for B SOA Seminar

  45. A -> B : Params from C. These include: mode: id_res B’s URL, session ID and nonce A’s ID as URL signed [mode, A’s ID as URL, B’s URL and nonce] The signature is encoded as Base 64 association_handle Opaque Handle used for looking up the signing key SOA Seminar

  46. Now, some options… • B ->C : The parameters and the signature – C checks the signature and informs B. B provides service to A. OR • B -> C : A request for the signing key • C -> B : The key is transmitted and B does the checking. B provides service to A. OR • B verifies the signature with a key he has built with C using Diffie-Hellman. The key was established earlier. B provides the service to A. SOA Seminar

More Related