1 / 39

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.

angie
Download Presentation

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 • 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 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 Master of Information System Management

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

  7. SAML 2.0 is widely implemented IBM Tivoli Access Manager Oblix NetPoint SunONE Identity Server Entegrity Solutions Assure Access, 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, management 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 into messages 95-843 SOA Security SAML

  13. Important 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) • Part of 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. 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 95-843 SOA Security SAML 14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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 or idP. • 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 should be over SSL. Why? 95-843 SOA Security SAML

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

  31. Authorization Use Case A user attempts to access a resource. The security domain defines a Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). 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

  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 channel and everything over SSL. 95-843 SOA Security SAML

  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. He trusts Trent. (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

  34. SAML Replay Attack • It’s hard for the bad guys to get a signed token. The signed token is carried over an SSL connection. • But, in principle, the bad guy does not need to be able to read the encrypted token in order to run a replay attack. • Timestamps on the token can be checked by the Service Provider. Is the request fresh? • ID’s on the token can be checked by the service provider. Have we seen this request before? 95-843 SOA Security SAML

  35. OpenID • Grassroots effort since 2005 • Now called Open ID Connect • Web user identification and authentication • OpenID used and provided by: AOL, BBC, Google, IBM, PayPal, Verisign, etc. • Governments and Universities are using SAML2 • OpenID Connect based on JSON & REST 95-843 SOA Security SAML

  36. The OpenID protocol • 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

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

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

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