Upload
angie
View
30
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
95-843 SOA Security SAML 1Master of Information System
Management
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
95-843 SOA Security SAML 2
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 3
95-843 SOA Security SAML 4Master of Information System
Management
The Needham–Schroeder Secret-Key Authentication Protocol
Header Message Notes
1. A->S: A, B, NAA requests S to supply a key for communicationwith B.
2. S->A: {NA , B, KAB,
{KAB, A}KB}KA
S returns a message encrypted in A’s secret key,containing a newly generated key KAB and a‘ticket’ encrypted in B’s secret key. The nonce NA demonstrates that the message was sent in responseto the preceding one. A believes that S sent themessage because only S knows A’s secret key.
3. A->B: A sends the ‘ticket’ to B.
4. B->A: B decrypts the ticket and uses the new key KAB toencrypt another nonce NB.
5. A->B: A demonstrates to B that it was the sender of theprevious message by returning an agreedtransformation of NB.
{KAB, A}KB
{NB}KAB
{NB - 1}KAB
95-843 SOA Security SAML 5Master of Information System
Management
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 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 is different from other security approaches mostly because ofits 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
SAML Web Service Use Case
95-843 SOA Security SAML 9
“In the information systems security space, identity management recentlyemerged 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 providesthe actual authentication service…”
From IBM Developerworks
What is Identity Management?
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
95-843 SOA Security SAML 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 1495-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 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
<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>
A SAML WS Response
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 aSAML authority.
The recipient is normallya 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
Relying Party or Service Provider
SAML RequestSAML Query
SAML ResponseAssertions
ServiceRequest
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)
(1)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 providetokens to Trent.
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 34
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 & REST95-843 SOA Security SAML 35
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 36
• 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 37
• 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 key95-843 SOA Security SAML 38
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 39