1 / 48

Master of Information System Management

Service Oriented Architecture. Identification, Authentication and Authorization. Master of Information System Management. Readings on Schedule. See SAML Executive Summary See SAML Technical Overview Read about PubCookie See A SAML Application - Shibboleth. Today ’ s Outline.

rona
Télécharger la présentation

Master of Information System Management

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. Service Oriented Architecture Identification, Authentication and Authorization 95-843 SOA Security SAML Master of Information System Management

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

  3. Today’s Outline • Identity Management 101 Video from Ping Identity • SAML video from Ping Identity • The Needham-Schroeder protocol • SAML • XACML • OpenID 95-843 SOA Security SAML

  4. The Needham–Schroeder Secret-Key Authentication Protocol Header Message Notes 1. A->S: A requests S to supply a key for communication A, B, NA with B. S returns a message encrypted in A’s secret key, 2. S->A: {NA , B, KAB, containing a newly generated key KAB and a {KAB, A}KB}KA ‘ticket’ encrypted in B’s secret key. The nonce NA demonstrates that the message was sent in response to the preceding one. A believes that S sent the message because only S knows A’s secret key. A sends the ‘ticket’ to B. {KAB, A}KB 3. A->B: B decrypts the ticket and uses the new key KAB to {NB}KAB 4. B->A: encrypt another nonce NB. A demonstrates to B that it was the sender of the {NB - 1}KAB 5. A->B: previous message by returning an agreed transformation of NB. 95-843 SOA Security SAML 4 Master of Information System Management

  5. The Needham–Schroeder Secret-Key Authentication Protocol Quiz. (0) With respect to Needham-Schroeder, discuss Identification, Authentication and Authorization. (1) What benefits are present in the separation of concerns that have been built into Needham-Schroeder? (2) Why would this protocol work well on an intranet but, at the same time, be hard to scale to the internet? 95-843 SOA Security SAML 5 Master of Information System Management

  6. SAML 2.0 Approved by OASIS, March 2005 Security Assertion Markup Language 95-843 SOA Security SAML

  7. 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. 95-843 SOA Security SAML

  8. 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 95-843 SOA Security SAML

  9. 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 95-843 SOA Security SAML

  10. 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

  11. 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. 95-843 SOA Security SAML

  12. SAML 2.0 Bottom Line • XML encoded security assertions • XML encoded Request/Reply protocol • Rules on how to incorporate these XML constructs in messages 95-843 SOA Security SAML

  13. 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 95-843 SOA Security SAML

  14. 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. 95-843 SOA Security SAML

  15. 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. 95-843 SOA Security SAML

  16. 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 95-843 SOA Security SAML

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

  18. 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? 95-843 SOA Security SAML

  19. 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> 95-843 SOA Security SAML

  20. Attribute Query <Request…> <AttributeQuery> <Subject>…</Subject> <AttributeDesignator AttributeName=“CreditRating” 95-843 SOA Security SAML

  21. 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> 95-843 SOA Security SAML

  22. SAML WS Response SOAP BODY SAML Response Header Assertion Statement Statement 95-843 SOA Security SAML

  23. 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> 95-843 SOA Security SAML

  24. SAML 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. 95-843 SOA Security SAML

  25. Authentication Statement <Assertion> : <AuthenticationStatement> : <ConfirmationMethod> 95-843 SOA Security SAML

  26. Attribute Statement <Assertion> : <AttributeStatement> <Attribute AttrributeName = “PaidStatus” <AttributeValue>PaidUp 95-843 SOA Security SAML

  27. Authorization Decision Statement T decides whether to grant a request by S for access (of a particular type) to resource R given evidence E. 95-843 SOA Security SAML

  28. Authorization Decision Statement <Assertion> : <AuthorizationStatement decision=“permit” resource = “salaryData” action=“read” 95-843 SOA Security SAML

  29. 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. 95-843 SOA Security SAML

  30. Trusted SAML Authority SAML Request SAML Query SAML Response Assertions Relying Party or Service Provider Service Request 95-843 SOA Security SAML

  31. 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. 95-843 SOA Security SAML

  32. 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. 95-843 SOA Security SAML

  33. 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. 95-843 SOA Security SAML

  34. 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. 95-843 SOA Security SAML

  35. 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. 95-843 SOA Security SAML

  36. XACML 2.0 Approved by OASIS March 2005 XML Access Control Markup Language 95-843 SOA Security SAML

  37. 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. • Seperation of concerns: Don’t bake • authorization policies into code. 95-843 SOA Security SAML

  38. Who Implements XACML? Oracle BEA SUN Microsoft ? Not yet. IBM 95-843 SOA Security SAML

  39. 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. 95-843 SOA Security SAML

  40. Drivers • A standard is needed so that policies can be processed and shared • Interoperable • Distributed • Separation of concerns 95-843 SOA Security SAML

  41. 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. 95-843 SOA Security SAML

  42. 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> 95-843 SOA Security SAML

  43. 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> 95-843 SOA Security SAML

  44. 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. • Highly scalable – does not depend on pre-existing agreements. 95-843 SOA Security SAML

  45. 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 95-843 SOA Security SAML

  46. 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 95-843 SOA Security SAML

  47. 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 95-843 SOA Security SAML

  48. 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. 95-843 SOA Security SAML

More Related