# Presentation: 950915

## Globus Securitywith SAML, Shibboleth, and GridShib

- 2:30pm, May 4, Faculty Club, UCSD
**GT4 Tutorial, **May 3-4, 2005, San Diego
- Frank Siebenlist - Argonne National Laboratory
- (franks@mcs.anl.gov)
- http://www.globus.org/

## Acknowledgements

- Eve Maler (Sun)
- Prateek Mishra (Netegrity)
- Tom Scavo (NCSA)
- Von Welch (NCSA)
- RL “Bob” Morgan (UofWashington)
- Steven Carmody (BrownU)
- Scott Cantor (OhioStateU)
- Tom Barton (UofChicago)
- Jim Basney (NCSA)
- Veronika Nefadova (ANL)

- Sam Meder (ANL)
- Jarek Gawor (ANL)
- Rachana Ananthakrishnan (ANL)
- Olle Molmo (KTH)
- Takuya Mori (NEC/ANL)
- Kate Keahey (ANL)
- Tim Freeman (UofChicago)
- David Champion (UofChicago)

- Globus Security

- May 4, 2005

## Outline

- SAML Introduction
- Shibboleth Introduction
- GridShib Introduction
- Globus Security

- Globus Security

- May 4, 2005

## SAML

- Globus Security

- May 4, 2005

## SAML Introduction

- The problem space
- SAML concepts
- Walking through scenarios
- Status of SAML and related standards efforts
- SAML 2.0
- (thanks to Eve Maler (Sun), Tom Scavo (NSCA) and Prateek Mishra (Netegrity) for some material in this presentation)

- Globus Security

- May 4, 2005

## What problems does SAML try to solve?

- Permissions management data is shared in mostly proprietary ways
- Integrating new security features may require developing a lot of new code
- The different systems that generate and use security data are very tightly coupled
- Web-based applications show the need for more federation
- We need to cross domains more easily

- Globus Security

- May 4, 2005

## SAML use cases in more detail

- SAML developed three “use cases” to drive its requirements:
- Single sign-on (SSO)
- Authorization service
- Back office transaction
- Each use case has one or more “scenarios” that provide a more detailed roadmap of interaction

- Globus Security

- May 4, 2005

**Notes:**
The SAML “use cases” are reminiscent of aggregations of UML-style use cases, rather than individual ones, so the name isn’t quite accurate.
The “scenarios” are message flow diagrams that have quite a bit of detail in them.
Ultimately, these (developed as part of our requirements-gathering process) are being turned into designs for what SAML calls “profiles”.

## SSO use case

- Globus Security

- May 4, 2005

**Notes:**
Steps:
Web user authenticates to the source Web site.
Web user uses a secured resource at the destination Web site.
This use case has specific push and pull scenarios.

Harking back to our web application scenario a few slides back: Logged-in users of analyst research site SmithCo are allowed access to research produced by sister site JonesCo.

## Authorization service use case

- Globus Security

- May 4, 2005

**Notes:**
Steps:
User accesses a resource controlled by PEP.
PEP checks permission for user to access resource with PDP.

## Back office transaction use case

- Globus Security

- May 4, 2005

**Notes:**
Harking back to our web application scenarios a few slides back: Employees at SmithCo are allowed to order office supplies from OfficeBarn if they are authorized to spend enough.
This is a modification of the original use case in the SAML requirements document. It was developed with the help of the editor of the SAML bindings document.

## What’s needed

- A standard XML message format
- It’s just data traveling on any wire
- No particular API mandated
- Lots of XML tools available
- A standard message exchange protocol
- Clarity in orchestrating how you ask for and get the information you need
- Rules for how the messages ride “on” and “in” transport protocols
- For better interoperability

- Globus Security

- May 4, 2005

**Notes:**
With XML, you often see standards that are simply wire protocols; no API is mandated, and in some cases no binding to some transport mechanism (such as HTTP or SMTP or whatever) is provided. We felt that the latter is definitely needed so that proprietary mechanisms don’t creep in.

## SAML Agenda

- The problem space
- SAML concepts
- SAML in a nutshell
- Producers and consumers of assertions
- Message exchange protocol
- Bindings and profiles
- Walking through scenarios
- Status of SAML and related standards efforts
- SAML 2.0

- Globus Security

- May 4, 2005

## SAML in a nutshell

- It’s an XML-based framework for exchanging security information
- XML-encoded security “assertions”
- XML-encoded request/response protocol
- Rules on using assertions with standard transport and messaging frameworks
- It’s an OASIS standard (1.0, 1.1 and 2.0)
- Vendors *and* users are involved
- Codifies current system outputs rather than inventing new technology

- Globus Security

- May 4, 2005

**Notes:**
Original SAML players: Netegrity and Securant (since acquired by RSA) contributed the initial specifications (S2ML, AuthXML). There were other contributions as well that were more peripheral to SAML’s core purpose.
Other major vendors/contributors: These include, for example, Baltimore, BEA, Entrust, Entegrity, HP, IBM/Tivoli, Oblix, Sun, VeriSign, Jamcracker, and Internet2/Shibboleth.
Areas of expertise: Distributed systems development, PKI, and XML.
What about Microsoft? They didn't participate in our early work, but they received some "encouragement" to take a look at SAML later. They have contributed design ideas, mostly about Kerberos support. A subcommittee has formed to pursue this more. The latest .NET/Passport story addresses "federated" functions, based on Kerberos. They have made no commitment to SAML, but the lines of communication have been opened.

## SAML Agenda

- The problem space
- SAML concepts
- SAML in a nutshell
- SAML assertions
- Producers and consumers of assertions
- Message exchange protocol
- Bindings and profiles
- Walking through scenarios
- Status of SAML and related standards efforts
- SAML 2.0

- Globus Security

- May 4, 2005

## SAML assertions

- An assertion is a declaration of fact about a subject, e.g. a user
- (according to some assertion issuer)
- SAML has three kinds, all related to security:
- Authentication
- Attribute
- Authorization decision
- You can extend SAML to make your own kinds of assertions
- Assertions can be digitally signed

- Globus Security

- May 4, 2005

**Notes:**
Typically a subject is human -- it’s somebody who is trying to accomplish some task on a computer and who needs to be checked out before they’re allowed to proceed.  But a subject can equally well be another computer/program.
SAML has the XML Signature standard from W3C/IETF baked into it.

## All assertions have some common information

- Issuer and issuance timestamp
- Assertion ID
- Subject
- Name plus the security domain
- Optional subject confirmation, e.g. public key
- “Conditions” under which assertion is valid
- SAML clients *must reject* assertions containing unsupported conditions
- Special kind of condition: assertion validity period
- Additional “advice”
- E.g., to explain how the assertion was made

- Globus Security

- May 4, 2005

**Notes:**
If an assertion is a declaration of fact according to some issuer, then it’s really important to document who said something.
Validity periods become important because not all assertions will be good forever. It’s an important security consideration in SAML to make the validity period be as short as is practicable.
SAML conditions are a little bit like SOAP mustUnderstand. You can add you own conditions on top of SAML. Such a feature can be open to abuse and lock-in by proprietary systems. Ideally new conditions will be standardized or at least openly published.

## Authentication assertion

- An issuing authority asserts that:
- subject S
- was authenticated by means M
- at time T
**Caution:** Actually checking or revoking of credentials is not in scope for SAML!
- Password exchange
- Challenge-response
- Etc.
- It merely lets you link back to acts of authentication that took place previously

- Globus Security

- May 4, 2005

**Notes:**
It was a hard decision not to put credential passing in scope for SAML 1.0 (for example, S2ML does it), but we probably would never finish because the whole problem is hard. We are examining credential pass-through to increase SAML’s utility in this area marginally.
A frequently asked question is: How secure is it to have this disconnect between the actual authentication and the sending of an authentication assertion? It is up to the system who needs the information to decide what authentication assertion issuers it chooses to trust.
The means of ensuring that the entity making a request and the entity referred to by an assertion are one and the same is dependent on the environment and protocols being used. The general mechanism provided is the SubjectConfirmation element, which is intended carry data appropriate to the environment (such as a public key).

## Example authentication assertion

**<****saml****:Assertion****  MajorVersion=“****1****” MinorVersion=“****0****”****  AssertionID=“****128.9.167.32.12345678****”****  Issuer=“****Smith Corporation****“****  IssueInstant=“****2001-12-03T10:02:00Z****”>****  <saml:Conditions****    NotBefore=“****2001-12-03T10:00:00Z****”****    NotAfter=“****2001-12-03T10:05:00Z****” />****  <saml:****AuthenticationStatement****    AuthenticationMethod=“****password****”****    AuthenticationInstant=“****2001-12-03T10:02:00Z****”>****    <saml:Subject>****      <saml:NameIdentifier****        SecurityDomain=“****smithco.com****”****        Name=“****joeuser****” />****    </saml:Subject>****  </saml:AuthenticationStatement>**** </saml:Assertion>**

- Globus Security

- May 4, 2005

**Notes:**
The saml: namespace corresponds to an XML Schema that just focuses on assertions.
So far, we have decided that unique identifiers like AssertionID are essentially opaque to SAML; it’s up to you to ensure that they’re unique in the domain you care about.

## Attribute assertion

- An issuing authority asserts that:
- subject S
- is associated with attributes A, B, ...
- with values “a”, “b”, “c”...
- Typically this would be gotten from an LDAP repository
- “john.doe” in “example.com”
- is associated with attribute “Department”
- with value “Human Resources”

- Globus Security

- May 4, 2005

## Example attribute assertion

**<saml:Assertion ...>****  <saml:Conditions .../>****  <saml:****AttributeStatement****>****    <saml:Subject>****      <saml:NameIdentifier****        SecurityDomain=“****smithco.com****”****        Name=“****joeuser****” />****    </saml:Subject>****    <saml:Attribute****      AttributeName=“****PaidStatus****”****      AttributeNamespace=“****http://smithco.com****”>****      <saml:AttributeValue>****        ****PaidUp****      </saml:AttributeValue>****    </saml:Attribute>****  </saml:AttributeStatement>****</saml:Assertion>**

- Globus Security

- May 4, 2005

**Notes:**
SAML requires attribute names to be qualified as being in a “namespace” (not an XML namespace), so that you can indicate the universe in which the attributes of interest were defined.  This makes SAML neatly extensible in this area.

## Authorization decision assertion

- An issuing authority decides whether to grant the request:
- by subject S
- for access type A
- to resource R
- given evidence E
- The subject could be a human or a program
- The resource could be a web page or a web service, for example

- Globus Security

- May 4, 2005

## Example authorization decision assertion

**<saml:Assertion ...>****  <saml:Conditions .../>****  <saml:****AuthorizationStatement****    Decision=“****Permit****”****    Resource=“****http://jonesco.com/rpt_12345.htm****”>****    <saml:Subject>****      <saml:NameIdentifier****        SecurityDomain=“****smithco.com****”****        Name=“****joeuser****” />****    </saml:Subject>****  </saml:AuthorizationStatement>****</saml:Assertion>**

- Globus Security

- May 4, 2005

## SAML Agenda

- The problem space
- SAML concepts
- SAML in a nutshell
- SAML assertions
- Producers and consumers of assertions
- Message exchange protocol
- Bindings and profiles
- Walking through scenarios
- Status of SAML and related standards efforts
- SAML 2.0

- Globus Security

- May 4, 2005

## SAML protocol for getting assertions

- Globus Security

- May 4, 2005

**Notes:**
We’re already familiar with assertions. They’re in the gray box here because SAML specifies them.
But they have to be delivered by authorities somehow; this is done in an XML document called a SAML response.
Of course, a response is produce in response to something. That something is an XML document called a SAML request.
And finally, these don’t live in a vacuum. We introduced the “authority” terminology a moment ago; a generic way of viewing issuers/producers/authorities is as asserting parties, and a generic way of viewing the systems that need, request, and use the assertions is as relying parties.

## Assertions are normally provided in a SAML response

- Existing tightly coupled environments may need to use their own protocol
- They can use assertions without the rest of the structure
- The full benefit of SAML will be realized where parties with no direct knowledge of each other can interact
- Via a third-party introduction

- Globus Security

- May 4, 2005

**Notes:**
Some scenarios for using SAML have, as part of their flow, raw assertions attached to other data. There’s nothing wrong with this, but if the SAML request-response protocol could be used for basic querying of authorities and isn’t, you might very well be missing an opportunity to interoperate with other systems.

## Authentication assertion request

- “Please provide the authentication information for this subject, if you have any”
- It is assumed that the requester and responder have a trust relationship
- They are talking about the same subject
- The response with the assertion is a “letter of introduction” for the subject

- Globus Security

- May 4, 2005

## Example authentication assertion request

**<****samlp****:Request**** MajorVersion=“****1****” MinorVersion=“****0****”****  RequestID=“****128.14.234.20.12345678****” >****  <samlp:****AuthenticationQuery****>****    <saml:Subject>****      <saml:NameIdentifier****        SecurityDomain=“****smithco.com****”****        Name=“****joeuser****” />****    </saml:Subject>****  </samlp:AuthenticationQuery>****</samlp:Request>**

- Globus Security

- May 4, 2005

## Attribute assertion request

- “Please provide information on the listed attributes for this subject”
- If the requester is denied access to some of the attributes, there are options for what gets returned
- Only the partial list of accessible attributes
- Either all of the attributes requested, or none

- Globus Security

- May 4, 2005

## Example attribute assertion request

**<samlp:Request ... >****  <samlp:****AttributeQuery****    CompletenessSpecifier=“****Partial****”>****    <saml:Subject>****      <saml:NameIdentifier****        SecurityDomain=“****smithco.com****”****        Name=“****joeuser****” />****    </saml:Subject>****    <saml:AttributeDesignator****      AttributeName=“****PaidStatus****”****      AttributeNamespace=“****http://smithco.com****”>****    </saml:AttributeDesignator>****  </samlp:AttributeQuery>****</samlp:Request>**

- Globus Security

- May 4, 2005

## Authorization decision assertion request

- “Is this subject allowed to access the specified resource in the specified manner, given this evidence?”
- This type of request is the most complex

- Globus Security

- May 4, 2005

## Example authorization decision assertion request

**<samlp:Request ...>****  <samlp:****AuthorizationQuery****    Resource=“****http://jonesco.com/rpt_12345.htm****”>****    <saml:Subject>****      <saml:NameIdentifier****        SecurityDomain=“****smithco.com****”****        Name=“****joeuser****” />****    </saml:Subject>****    <saml:Actions Namespace=“http://...”>****      <saml:Action>****Read****</saml:Action>        ****    </saml:Actions>****    <saml:Evidence>****      <saml:Assertion>****        ****...some assertion...****      </saml:Assertion>****    </saml:Evidence>****  </samlp:AuthorizationQuery>****</samlp:Request>**

- Globus Security

- May 4, 2005

**Notes:**
Just as for attributes, the potential actions are governed in a way that allows SAML not to be dependent on a “closed set” of them.

## Example response

**<samlp:Response**** MajorVersion=“****1****” MinorVersion=“****0****”****  RequestID=“****128.14.234.20.90123456****”****  InResponseTo=“****128.14.234.20.12345678****”****  StatusCode=“****Success****”>****  <saml:Assertion****    MajorVersion=“****1****” MinorVersion=“****0****”****    AssertionID=“****128.9.167.32.12345678****”****    Issuer=“****Smith Corporation****">****    <saml:Conditions****      NotBefore=“****2001-12-03T10:00:00Z****”****      NotAfter=“****2001-12-03T10:05:00Z****” />****    <saml:AuthenticationStatement**** ****...>****    </saml:AuthenticationStatement>****  </saml:Assertion>****</samlp:Request>**

- Globus Security

- May 4, 2005

**Notes:**
Responses aren’t very exciting to look at. They just contain assertions and some response metadata.
I haven’t covered the boxcarring of assertions here.

## SAML Agenda

- The problem space
- SAML concepts
- SAML in a nutshell
- SAML assertions
- Producers and consumers of assertions
- Message exchange protocol
- Bindings and profiles
- Walking through scenarios
- Status of SAML and related standards efforts
- SAML 2.0

- Globus Security

- May 4, 2005

## Bindings and profiles connect SAML with the wire

- This is where SAML itself gets made secure
- A “binding” is a way to transport SAML requests and responses
- SOAP-over-HTTP binding is a baseline
- WSS SAML Profile
- A “profile” is a pattern for how to make assertions about other information
- Web browser profile for SSO
- SOAP profile for securing SOAP payloads

- Globus Security

- May 4, 2005

**Notes:**
Profiles are sort of like choreography templates. SAML is very flexible; profiles give you a way to standardize on particular flows of SAML-related data in order to secure some other traffic.
The SAML committee is standardizing some of these, but we have every intention of seeing more created by others. We hope that these will be standardized by some body, or at least openly specified.

## The SOAP-over-HTTP binding

- Globus Security

- May 4, 2005

**Notes:**
This just amounts to using SOAP to query a SAML authority and get back a response.

## By contrast, the SOAP profile

- Globus Security

- May 4, 2005

**Notes:**
On the other hand, this is a canonical way to provide assertions about some resource that is in the body of the same SOAP document that the assertions are in.

## SAML Agenda

- The problem space
- SAML concepts
- Walking through scenarios
- SSO pull using web browser profile
- Back office transaction using SOAP binding and SOAP profile
- Status of SAML and related standards efforts
- SAML 2.0

- Globus Security

- May 4, 2005

## Back office transaction scenario

- Globus Security

- May 4, 2005

**Notes:**
This scenario has a different function and different players, but the flow is actually basically the same.
This time Joe User of SmithCo is trying to order some supplies from OfficeBarn. Joe knows about OfficeBarn, but OfficeBarn isn’t all that familiar with Joe.
The key here is that both Joe/SmithCo and OfficeBarn have an authentication/attribute authority that they’re both willing to trust.
Joe logs in.
He asks for and gets the assertions that say he’s logged in (authentication) and that he’s got a corporate spending limit of $500 (attribute).
These get attached to the purchase order he sends to OfficeBarn.
OfficeBarn looks everything over.
Then it acts appropriately.

## More on the back office transaction scenario

- An example of attaching SAML assertions to other traffic
- Asymmetrical relationship is assumed
- Seller is already known to buyer, but buyer is not known to seller, a common situation
- E.g., server-side certificates might be used to authenticate seller
- If it were symmetrical, additional SAML steps would happen on the right side too
- This would likely be a different scenario

- Globus Security

- May 4, 2005

**Notes:**
The typical business case is asymmetrical in that it involves (fewer) well-known sellers and many buyers, not all of whom have a direct relationship to the seller.
The symmetric case is a different business model. I send my RFQ (Request for Quote) with attached assertions to an aggregator who sends it out to many different business entities. The business entities respond with Quotations and include attached assertions to qualify and validate their quotations. I evaluate the returned Quotations and Assertions and choose a vendor.

## SAML Agenda

- The problem space
- SAML concepts
- Walking through scenarios
- Status of SAML and related standards efforts
- SAML 2.0

- Globus Security

- May 4, 2005

## SAML Standards History

- SAML 1.0May 2002

- SAML 1.1May 2003

- LA 1.1January 2003

- ID-FF 1.2October 2003

- LA: Liberty Alliance                 ID-FF: Identity Federation Framework                                    SAML: Security Assertion Markup LanguageXACML: Extensible Access Control Markup Language

- Shibboleth1H03

- XACML1.0February 2003

- WSS SAML Token Profile Q4/04

- Formally submitted to the SSTC

- SAML 2.0Q1/2005

- XACML 2.0Q1/2005

- WSS  SOAP Security Q4/03

- Globus Security

- May 4, 2005

## SAML-2.0 Normative Specification Set

- Conformance Requirements for the OASIS SAML V2.0
- Entry point for entire specification set
- Assertions and Protocols for the OASIS SAML V2.0
- SAML assertions schema [SAMLAssn-xsd]
-  SAML protocols schema [SAMLProt-xsd]
- Bindings for the OASIS SAML V2.0
- Profiles for the OASIS SAML V2.0
- Metadata for the OASIS SAML V2.0
- SAML metadata schema [SAMLMeta-xsd]
- Authentication Context for the OASIS SAML V2.0
- Various authentication context schema files
- Security and Privacy Considerations for the OASIS SAML V2.0
- Glossary for the OASIS SAML V2.0

- Globus Security

- May 4, 2005

## Specification Actors and Topics

- IdentityProvider
- Session AuthorityAttributeProvider

- Service ProviderSessionParticipant
- Attribute Consumer

- Trust Relationship

- AttributeProvider

- IdentityFederation

- SessionMngmt

- AttributeServices

- AttributeConsumer

- Metadata

- Actors

- Actors

- UserClients

- UserClients

- Specification Topics

- SSO

- Globus Security

- May 4, 2005

## Agenda

- SAML 2.0 Overview
- _SAML 2.0 Feature Set_
- Federation Models in SAML 2.0
- Conclusion

- Globus Security

- May 4, 2005

## SAML 2.0 Feature Set

- SSO
- Identity Federation
- Sessions and Logout
- Attribute Services
- Metadata

- Globus Security

- May 4, 2005

## SAML 2.0 Terminology

- SAML 2.0 terminology used throughout:
*Identity Provider* (IdP)
- Authentication Authority
- Single Sign-On Service
- Artifact Resolution Service
- Attribute Authority
*Service Provider* (SP)
- Assertion Consumer Service
- Attribute Requester
- Artifact Resolution Service (SAML 2.0 only)

- Globus Security

- May 4, 2005

## Single-Sign On

- Browser-driven SSO
- Form POST, SAML Artifact Profiles
- Note: conformant implementations must implement both profiles
- Assertions may contain attribute statements
- SAML 2.0 introduces notion of attribute profile
- All or certain parts of an assertion may be encrypted
- Important when security intermediaries are involved
- SSO for enhanced client
- Enhanced client is a device that understands HTTP but not SOAP
- Also has “built in” knowledge of identity provider
- Examples
- HTTP proxies such as a WAP gateway
- Consumer device with HTTP client

- Globus Security

- May 4, 2005

## SAML 2.0 Feature Set

- SSO
- _Identity Federation_
- What is (SAML 2.0) identity federation?
- Well known name or attribute
- Anonymous user Identified by attributes or roles
- User identified by privacy-preserving identifier
- Affiliations
- Managing and updating identity federations
- Privacy and user Consent
- Sessions and Logout
- Attribute Services
- Metadata

- Globus Security

- May 4, 2005

## What is identity federation?

- Agreement between an identity provider and one or more service providers concerning the data using which users will be described
- By their e-mail address?
- By their office number and employee Id?
- By their role or membership in certain groups?
- By a unique (privacy preserving) identifier known only to the IdP and SP?
- Agreement creation may be accomplished in different ways
- Business agreements between IdP and SP’s
- In some cases may require bulk update or synchronization of parts of the user store at both ends

- Globus Security

- May 4, 2005

## Well known name or attribute

- SAML 2.0 supports the use of:
- Email Address
- X.509 Subject Name
- Windows Domain Qualified Name
- Kerberos Principal Name
- Attribute (e.g., employee number)
- User entry at the IdP and SP(s) are keyed off the name or attribute
- Privacy preservation is not an issue here
- Names may be encrypted to protect against intermediaries
- Common use-case in many SAML 1.X deployments

- Globus Security

- May 4, 2005

## Anonymous user with attributes or roles

- User is never explicitly identified by a persistent identifier
- A transient identifier is used as the “name” of the user
- One or more roles or attributes describe the user
- EmploymentLevel : Manager
- AccessRights: Platinum
- MemberOf: BellRingers
- Access at Service Provider is given against roles or attributes
- No need to maintain user entry at SP
- Privacy Preserving as user identity at IdP remains unknown
- Main use case in Shibboleth and some SAML 1.X deployments

- Globus Security

- May 4, 2005

## User identified by privacy-preserving identifier

- User is identified by a persistent randomized string private to IdP and SP pairs
- Unique handle per service provider
- Privacy-preserving since no information about user is available at SP
- Requires IdP and SP to synchronize portions of their user stores
- Affiliations:  important sub-case where a single persistent randomized string is shared between a set of Service Providers
- Main use case in ID-FF 1.X specifications and deployments

- Globus Security

- May 4, 2005

## Name Identifier Management

- Protocol for communicating information about name identifiers
- When identifiers should be updated
- Replace _[jsmith@foo.com](mailto:jsmith@foo.com)_ by _[johns@foo.com](mailto:johns@foo.com)_
- Rollover privacy preserving identifier at SP every 6 months
- Update identifier at IdP with identifier meaningful to SP
- When an identifier will no longer be acceptable for federation
- IdP will not issue any more assertions for _[jsmith@foo.com](mailto:jsmith@foo.com)_
- SP will not accept assertions for jsmith@foo.com

- Globus Security

- May 4, 2005

## Privacy and User Consent

- Privacy
- SAML 2.0 includes recommendations for privacy preservation if and when desired
- Main idea is that Identity providers need not release _any_ personal information about users to service providers
- User Consent
- SSO protocol includes ability to query and record user-consent
- Identity providers and service providers can choose to provide services based on whether user-consent was obtained and recorded

- Globus Security

- May 4, 2005

## SAML 2.0 Feature Set

- Overview
- SSO
- Identity Federation
- _Sessions and Logout_
- Attribute Services
- Metadata

- Globus Security

- May 4, 2005

## Sessions and Logout

- Identity providers as session authorities, service providers as session participants
- Identity providers provide session identifier(s) to service providers
- User may logout at IdP or SP to terminate session
- Ability to terminate all or some sessions of a user
- Solution follows ID-FF 1.2 closely (logout but no timeout) but also provides extension points for richer session models
- Instructions for privacy preservation are provided
- Multiple service providers should not be able to collude and determine if it is the “same” user who is participating in a shared session

- Globus Security

- May 4, 2005

## Attribute Services

- Support for attribute names and values drawn from a variety of syntaxes
- Basic Attribute Profile: string names and attribute values drawn from XML schema primitive type definitions
- X.500/LDAP Attribute Profile: use of canonical X.500/LDAP attribute names and values
- UUID Attribute Profile: Use of UUIDs as attribute names
- XACML Attribute Profile: formats suitable for processing by XACML
- Attributes statements may be transferred during SSO or by the use of the AttributeQuery protocol
- Attributes may be encrypted to ensure end-to-end confidentiality

- Globus Security

- May 4, 2005

## Metadata

- Identifies the distinct roles or actors involved in profiles
- SSO Identity Provider
- SSO Service Provider
- Attribute Authority
- Attribute Requester
- Specifies data that must be agreed upon between system entities regarding identifiers, supported profiles, URLs, certificates and keys
- Configuration data
- Trust data
- Will aid improved deployability of SAML components

- Globus Security

- May 4, 2005

## SAML-2.0 Conclusion

- SAML 2.0 integrates deployment experience from SAML 1.1 and Shibboleth, and new protocols from ID-FF 1.2 into a single standard
- Supports flexible identity federation models corresponding to different business use-cases
- Provides a complete solution for identity federation for web applications with no missing “last mile” pieces

- Globus Security

- May 4, 2005

## Shibboleth

- Globus Security

- May 4, 2005

## Shibboleth Architecture and Requirements

- Introduction to Shibboleth
- Key concepts
- Deploying Shibboleth
- (thanks to Steven Carmody, Scott Cantor, RL “Bob” Morgan, Tom Scavo for some material in this presentation)

- Globus Security

- May 4, 2005

## What is Shibboleth?

- An Architecture and Protocol
- A set of profiles based on the OASIS SAML 1.1 standard
- A Project sponsored by Internet2/MACE
- Charged with defining the Shibboleth Arch, developing an open source implementation, and supporting the deploy of Shibboleth through the Higher Ed environment
- Develop an architecture and policy framework supporting the sharing – between domains -- of secured web resources and services
- An Implementation of the Shibboleth Architecture
- Developed by the I2/MACE Shibboleth Project
- There are other independent implementations

- Globus Security

- May 4, 2005

## Shibboleth Goals

- Use federated administration as the lever; have the enterprise broker most services (authentication, authorization, resource discovery, etc.) in inter-realm interactions
- Provide security while not degrading privacy.
- Attribute-based Access Control
- Foster inter-realm trust fabrics: federations and virtual organizations
- Leverage campus expertise and build rough consensus
- Influence the marketplace; develop where necessary
- Support for heterogenity and open standards

- Globus Security

- May 4, 2005

## Attribute-based Authorization

**IP Address-based approach**
- The resource checks the browser's IP address against a table.  Browsers using an IP address assigned to campus X are given campus X’s authorizations
- Most campuses run proxy servers, to allow access from off-campus
**Identity-based approach**
- The identity of a prospective user is passed to the controlled resource and is used to determine whether to permit access.
- This approach requires the user to trust the resource to protect privacy.
**Attribute-based approach**
- Attributes are exchanged about a prospective user until the controlled resource has sufficient information to make a decision. Identity MAY be an attribute...
- This approach does not degrade privacy.

- Globus Security

- May 4, 2005

## Shibboleth Status

- V1.2.1 available fall 2004
- In production use by commercial information providers (eg Elsevier SD, OCLC)
- Growing international takeup (countrywide deploys in HE underway in Switzerland, Finland, UK, Australia, and others...)
- Deploy rate on US campuses accelerating....
- Production Federations now available
- Recent meeting of “League of Federations”
- On track for certification by US Federal E-Authn Initiative

- Globus Security

- May 4, 2005

## What are federations?

- An association of organizations that use a common set of attributes, practices and policies to exchange information about their users and resources in order to enable collaborations and transactions.
- Built on the premise of
- “Enroll and authenticate and attribute locally, act federally.”
- Federation provides only modest operational support and consistency in how members communicate with each other
- Enterprises (and users) retain control over what attributes are released to a resource; the resources retain control (though they may delegate) over the authorization decision.
- Over time, this will all change...

- Globus Security

- May 4, 2005

## Shibboleth -- Next Steps

- Plan for a Multi-Federation World
- Improved management tools
- Shibboleth 1.3 early 2005
- Reduces reliance on inflexible PKI validation code
- e-Auth, compliance
- WS-Fed compliance in 1.3.x
- Shibboleth 2.0, using SAML 2.0, represents greatly enhanced functionality; work begins after 1.3 is released
- Shibboleth project will be segmented and expanded
- Extended beyond the web; some flows may not use all existing components in the same way

- Globus Security

- May 4, 2005

## The Architecture of Shibboleth

- Globus Security

- May 4, 2005

## High Level ArchitectureKnock, Knock...

- Globus Security

- May 4, 2005

## Shibboleth as Implemented by Internet2

- Java IdP, C++ SP for Apache and IIS, Java SP in development
- Extremely flexible and modular
- Built on included OpenSAML; supports SAML 1.0, 1.1, and will support 2.0
- Supports SAML Browser/POST profile
- SAML Artifact Profile will be supported in v1.3
- Other implementations exist

- Globus Security

- May 4, 2005

**Notes:**
Three total implementations as of 16.11.04

## Key Concepts

- SAML
- Attributes in an Inter-Realm Context
- Metadata and ProviderIDs
- Credentials and Relying Parties
- Attribute Release Policies (ARP’s)
- Attribute Acceptance Policies (AAP’s)

- Globus Security

- May 4, 2005

## SAML

- Security Assertion Markup Language
- Codified by OASIS’ SSTC with participation from MACE and other bodies
- Defines XML schema for Authentication and Attribute Assertions, Queries and Responses, and profiles of use like Web SSO
- Defines bindings to protocols for transport
- Many vendor implementations support SAML 1.x
- v2.0 expands to include concepts from Liberty Alliance and Shibboleth

- Globus Security

- May 4, 2005

## Shibboleth vs SAML

- Shibboleth is a profile of SAML
- Shibboleth Architecture document describes how Shibboleth uses SAML
- Shibboleth extends SAML, defining a new NameIdentifier (the Handle)
- The Shibboleth implementation includes a trust fabric implementation based on PKI
- The Shibboleth implementation includes a framework and metadata for identifying IdPs and SPs
- The Shibboleth implementation includes a mechanism (ARPs) to manage the release of attribute information to SPs

- Globus Security

- May 4, 2005

## Attributes in an Inter-Realm Context

- Provided by IdP, validated and evaluated by SP
- Converted to SAML form for transport
- Federations guide usage of common attributes and values, e.g. eduPerson, courseID
- Others defined within bilateral relationships
- Who can assert which attributes?
- What level of assurance is there that this data is accurate?

- Globus Security

- May 4, 2005

## LDAP to SAML as performed by AA

- LDAP:
- objectclass: eduPerson
- dn: uid=magneto, ou=people, dc=supervillain, dc=edu
- eduPersonAffiliation: staff
- SAML:
- <Attribute
-    AttributeName="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"
-    AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
- <AttributeValue Scope=”supervillain.edu">
- 	staff
- </AttributeValue>
- </Attribute>

- Globus Security

- May 4, 2005

**Notes:**
Focus on AttributeName, scope

## Metadata and ProviderIDs

- A ProviderID is the basic atom of inter-realm policy and trust; the molecule is the enterprise
- URI (urn:mace:inqueue:supervillain.edu, or https://dspace.osu.edu/shibboleth)
- Each SP or IdP deployment may encompass multiple logical "providers"
- XML-based "metadata" about providers in a federation is exchanged to configure and secure interactions
- Must be carefully defined; defines distributed use of enterprise Shibboleth infrastructure
- Care must be taken when defining ProviderIDs for single or multiple federation use

- Globus Security

- May 4, 2005

**Notes:**
Does that make the federation the solution?  Stress difference between providerID’s and URL’s

## Credentials and Relying Parties

- Metadata includes references to (or actual) the credentials used by providers within a federation to sign XML or create SSL connections
- A Relying Party is the other end in a transaction, and may represent an individual provider or a collection of providers
- Configuration of software enables decisions about behavior and credentials to be made per-relying-party, allowing flexibility

- Globus Security

- May 4, 2005

**Notes:**
Does that make the federation the solution?  Stress difference between providerID’s and URL’s

## Attribute Release Policies (ARPs)

- Policies at the IdP governing the release of attributes to various service providers (based on an SP's ProviderID, which is its "name")
- ARPs limit attributes released to a relying party on a global or per-user basis
- Can match individual SPs or regular-expression-based matches; supports both positive and negative attribute rules

- Globus Security

- May 4, 2005

## ARP Example

- <Rule>
- <Target>
- <AnyTarget/>
- </Target>
- <Attribute name=“urn:mace:dir:attribute-def:eduPersonScopedAffiliation”>
- <AnyValue release=“permit”/>
- </Attribute>
- </Rule>

- Globus Security

- May 4, 2005

## Shib Deployment Resources

- _[http://shibboleth.internet2.edu](http://shibboleth.internet2.edu/)_
- _[http://inqueue.internet2.edu](http://inqueue.internet2.edu/)_
- Origin:
- _[http://shibboleth.internet2.edu/guides/deploy-guide-origin-1.2.1.html](http://shibboleth.internet2.edu/guides/deploy-guide-origin-1.2.1.html)_
- _[http://shibboleth.internet2.edu/guides/identity-provider-checklist.html](http://shibboleth.internet2.edu/guides/identity-provider-checklist.html)_
- Target:
- _[http://shibboleth.internet2.edu/guides/deploy-guide-target-1.2.1.html](http://shibboleth.internet2.edu/guides/deploy-guide-target-1.2.1.html)_
- _[shibboleth-users@internet2.edu](mailto:shibboleth-users@internet2.edu)_

- Globus Security

- May 4, 2005

## GridShib

- Globus Security

- May 4, 2005

## GridShib: Grid-Shibboleth Integration(Identity Federation and Grids)

- NSF NMI project to allow the use of Shibboleth-issued attributes for authorization in NMI Grids built on the Globus Toolkit
- Funded under NSF award SCI-0438424
- Goal: GT 4.2 & Shibboleth 1.3
- GridShib team: NCSA, U. Chicago, ANL
- Tom Barton, David Champion, Tim Freemon, Kate Keahey, Tom Scavo, Frank Siebenlist, Von Welch
- Working in collaboration with Steven Carmody, Scott Cantor, Bob Morgan and the rest of the Internet2 Shibboleth Design team

- Globus Security

- May 4, 2005

## Why? 

- Leverage Shibboleth code base
- Someone else is writing and debugging it
- Leverage Shibboleth deployments
- Someone else is supporting them
- Leverage larger issues going on in Identity Federation world
- Someone else is helping to write them
- Even more someone else’s will be writing and deploying them
- SAML standard, profiles
- Leverage someone else’s attributes?
- Are campus attributes useful to Grids?

- Globus Security

- May 4, 2005

## Outline

- Low-level technical discussion
- Shibboleth
- GridShib
- Higher-level discussion of Identity Federation for Grids
- How do sites federate to support a VO?

- Globus Security

- May 4, 2005

## Shibboleth Federation Model

- Attrs

- IDs

- Attrs

- IDs

- SAML

- Globus Security

- May 4, 2005

## Shibboleth (Simplified)

- Attrs

- IDs

- WWW

- Shibboleth

- Handle

- Handle

- Attributes

- SAML

- Globus Security

- May 4, 2005

## GridShib (Simplified)

- Attrs

- IDs

- Grid

- Shibboleth

- DN

- Attributes

- DN

- DN

- SAML

- SSL/TLS, WS-Security

- Globus Security

- May 4, 2005

## GridShib Goals

- Work with others to standardize X509 profile for Shibboleth/SAML AA
- Change as little as possible on Shibboleth side
- Limit to installation of new NameMapper plug-in for Shibboleth to recognize and map DNs to local identities
- Privacy
- In “GridShib V2”

- Globus Security

- May 4, 2005

## GridShib Goals (cont)

- Modifications to GT to request, receive and parse SAML attributes from Shib
- General PDP functionality
- Grid uses cases can be very complicated and varied in terms of authz policy
- Try to support union of many “simple” cases
- Allow for deployment of custom PDPs

- Globus Security

- May 4, 2005

## GridShib Challenges

- Identity Provider Discovery
- Compounded by need in some grids to consult several identity providers for each user
- Distributed Attribute Administration
- What happens when the folks running the attribute authority are not the ones authoritative for the attributes?
- Some projects don’t have resources to run a 7x24 security service, but are the only ones who know the attribute space
- Explore Signet, Grouper

- Globus Security

- May 4, 2005

## Distributed Authorities

- Grid Service

- Session authentication credential

- Attribute Authority

- Home Org

- Virtual Org

- Affiliated Org

- Authorities

- Globus Security

- May 4, 2005

## GridShib Integration Goals

- Use Shibboleth 1.3 out of box
- With additional NameMapper module to handle mapping X.509 identities to local names
- Work with Shib identity provider metadata
- Working with Shib developers to achieve
- Don’t require modification to typical grid client applications for simple use cases
- Most of work going into Grid services

- Globus Security

- May 4, 2005

## GirShib Questions?

- Project website:
- _[http://grid.ncsa.uiuc.edu/GridShib/](http://grid.ncsa.uiuc.edu/GridShib/)_
- For more information on NMI:
- _[http://www.nsf-middleware.org/](http://www.nsf-middleware.org/)_

- Globus Security

- May 4, 2005

## Globus Security

- May 4, 2005

## Outline

- Part One
- The Big Picture
- What is Grid Security?
- Current Grid Security
- Part Two
- 2004: The year we lost control of the desktop
- Leverage Security Service Implementations
- GT’s Authorization Processing Framework
- Futures and Conclusion

- Globus Security

- May 4, 2005

## Security Services Objectives

- It’s all about “Policy”
- (Virtual) Organization’s Security Policy
- Security Services facilitate the enforcement
- Security Policy to facilitate “Business Objectives”
- Related to higher level “agreement”
- Security Policy often delicate balance
- More security  Higher costs
- Less security  Higher exposure to loss
- Risk versus Rewards
- Legislation sometimes mandates minimum security

- Globus Security

- May 4, 2005

## Agreement  VO Security Policy

- Price
- Cost
- Obligations
- QoS
- T&Cs
- ...............
- Security
- ...............

- trust anchors
- (initial) members
- (initial) resources
- (initial) roles
- Access rules
- Privacy rules

**(Business) Agreement**

**Dynamic **
**VO Security Policy**

- members
- resources
- roles
- Attribute mgmt
- Authz mgmt

**Static Initial**
**VO Security Policy **

- Globus Security

- May 4, 2005

## Virtual Organization Concept

- Globus Security

- May 4, 2005

## What is Grid Security?

***The Grid problem is to enable “coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations*****.”**
- From **The Anatomy of the Grid**
- So Grid Security is security to enable VOs
- What is needed in terms of security for a VO?

- Globus Security

- May 4, 2005

## Resource Sharing

*“...**coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations*.”
- Resources being used are still owned by their respective organization and subject to its policies
- Sharing may be controlled amongst a number of VOs
- Non-trivial policy in regards to QoS, QoP, etc.

- Globus Security

- May 4, 2005

## Controlled Resource Sharing

- ComputeCenter

- HEP VO

- Chem EngVO

- BIO VO

- 5pm-9amonly

- 20 Tflops per
- month max

- 100 Tbytes
- max

- 20 Mbytes/sec
- max

- Globally:
-  User must agreeto AUP
-  User must use strong authentication

- Globus Security

- May 4, 2005

## Requires Coordination by VO

*“...**coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations*.”
- Resources contributed to VO need to be coordinated by the VO in order to work together effectively.
- All need to have a coherent policy in order to interoperate
- Requires policy from VO back to resources

- Globus Security

- May 4, 2005

## Dynamic Users, Resources, Policies

*“...**coordinated resource sharing and **problem solving in dynamic, **multi-institutional virtual organizations*.”
- Users, resources may be large, unpredictable, and changing at any point
- Roles of both may also be distinct and dynamic (not all users are equal).
- Doesn’t allow for static configuration

- Globus Security

- May 4, 2005

## Multiple Organizations, Mechanisms, Policies

*“...**coordinated resource sharing and **problem solving in dynamic, **multi-institutional virtual organizations*.”
- Each resource and user will have local policies and technologies that cannot be replaced by the VO
- Cannot assume cross-organizational trust relationships

- Globus Security

- May 4, 2005

## Multi-Institution Issues

**Certification**

**Authority**

**Certification**

**Authority**

**Domain A**

**Server X**

**Server Y**

**Policy**

**Authority**

**Policy**

**Authority**

**Task**

**Domain B**

**Sub-Domain A1**

**Sub-Domain B1**

- Globus Security

- May 4, 2005

## Why Grid Security is Hard

- Resources being used may be valuable & the problems being solved sensitive
- Both users and resources need to be careful
- Dynamic formation and management of virtual organizations (VOs)
- Large, dynamic, unpredictable...
- VO Resources and users are often located in distinct administrative domains
- Can’t assume cross-organizational trust agreements
- Different mechanisms & credentials
- X.509 vs Kerberos, SSL vs GSSAPI, X.509 vs. X.509 (different domains),
- X.509 attribute certs vs SAML assertions

- Globus Security

- May 4, 2005

## Why Grid Security is Hard...

- Interactions are not just client/server,  but service-to-service on behalf of the user
- Requires delegation of rights by user to service
- Services may be dynamically instantiated
- Standardization of interfaces to allow for discovery, negotiation and use
- Implementation must be broadly available & applicable
- Standard, well-tested, well-understood protocols; integrated with wide variety of tools
- Policy from sites, VO, users need to be combined
- Varying formats
- Want to hide as much as possible from applications!

- Globus Security

- May 4, 2005

## The Grid Trust solution

- Instead of setting up trust relationships at the organizational level (lots of overhead, possible legalities - expensive!) set up trust at the user/resource level
- Virtual Organizations (VOs) for multi-user collaborations
- Federate through mutually trusted services
- Local policy authorities rule
- Users able to set up dynamic trust domains
- Personal collection of resources working together based on trust of user

- Globus Security

- May 4, 2005

## Grid Solution:Use Virtual Organization as Bridge

- Grid Solution:Use Virtual Organization as Bridge

**Certification**

**Domain A**

**GSI**

**Federation**

**Service**

**Virtual**

**Organization**

**Domain**

- No Cross-
- Domain Trust

- Globus Security

- May 4, 2005

## Effective Policy GoverningAccess Within A Collaboration

- Globus Security

- May 4, 2005

## Use Delegation toEstablish Dynamic Distributed System

- ComputeCenter

- VO

- Rights

- ComputeCenter

- Service

- Globus Security

- May 4, 2005

## Goal is to do this with arbitrary mechanisms

- ComputeCenter

- VO

- Rights

- ComputeCenter

- Kerberos/
- WS-Security

- X.509/SSL

- SAMLAttribute

- X.509AC

- SAMLAttribute

- X.509AC

- Globus Security

- May 4, 2005

## Security ofGrid Brokering Services

-  It is expected brokers will handle resource coordination for users
-  Each Organization enforces its own access policy
-  User needs to delegate rights to broker which may need to delegate to services
- QoS/QoP Negotiation and multi-level delegation

- Globus Security

- May 4, 2005

## Propagation of Requester’s Rights through Job Scheduling and Submission Process

- Dynamically limit the Delegated Rights more as Job specifics become clear

- Trust parties downstream to limit rights for you...or let them come back with job specifics such that you can limit them

- Virtualization complicates Least Privilege Delegation of Rights

- Globus Security

- May 4, 2005

## Grid Security must address...

- Trust between resources without organization support
- Bridging differences between mechanisms
- Authentication, assertions, policy...
- Allow for controlled sharing of resources
- Delegation from site to VO
- Allow for coordination of shared resources
- Delegation from VO to users, users to resources
- ...all with dynamic, distributed user communities and least privilege.

- Globus Security

- May 4, 2005

## Security Layers

- Authorization

- Delegation

- Authentication

- Message
- Protection

- Message
- Format

- SOAP

- WS-Security/WS-SecureConversation

- X.509 ID Certificates

- X.509 Proxy Certificates/SAML/XACML

- Grid-Mapfile/SAML/XACML

- Globus Security

- May 4, 2005

## Grid Security Infrastructure (GSI)

- Use GSI as a standard mechanism for bridging disparate security mechanisms
- Doesn’t solve trust problem, but now things talk same protocol and understand each other’s identity credentials
- Basic support for delegation, policy distribution
- Translate from other mechanisms to/from GSI as needed
- Convert from GSI identity to local identity for authorization

- Globus Security

- May 4, 2005

## Grid Security Infrastructure (GSI)

- Based on standard PKI technologies
- CAs allow one-way, light-weight trust relationships (not just site-to-site)
- SSL protocol or WS-Security for authentication, message protection
- X.509 Certificates for asserting identity
- for users, services, hosts, etc.
- Proxy Certificates
- GSI extension to X.509 certificates for delegation, single sign-on

- Globus Security

- May 4, 2005

## Grid Identity, Local Policy

- LocalPolicy

- LocalPolicy

- Map tolocal name

- Map tolocal name

- Grid
- Identity

-  In current model, all Grid entities assigned a PKI identity.
-  User is mapped to local identities to determine local policy.
- .

- Globus Security

- May 4, 2005

## Kerberos to GSI Gateway

- To use Kerberos, a Kerberos-to-GSI gateway translates Kerberos credentials to GSI credentials to allow local Kerberos users to authenticate on the Grid.
- Kx509/KCA is an implementation of one such gateway.
- Sslk5/pkinit provide the opposite functionality to gateway incoming Grid credentials to local Kerberos credentials.

- Globus Security

- May 4, 2005

## Local Identity,Grid Identity, Local Policy

- LocalPolicy

- Map tolocal name

- Grid
- Identity

- KerberosSite

- KCA

- SSLK5

- KRB5
- Resources

- Globus Security

- May 4, 2005

## GSI Implementation

- ComputeCenter

- VO

- Rights

- VOUsers

- Services (running
- on user’s behalf)

- Rights’’

- Rights’

- Access

- Authz Callout

- KCA

- MyProxy

- Globus Security

- May 4, 2005

## X.509 Proxy Certificates

- GSI Extension to X.509 Identity Certificates
- RFC 3820
- Support being added to OpenSSL
- Enables single sign-on
- Allow user to dynamically assign identity and rights to service
- Can name services created on the fly and give them rights (i.e. set policy)
- What is effectively happening is the user is creating their own trust domain of services
- Services trust each other with user acting as the trust root

- Globus Security

- May 4, 2005

## Proxy Certificates

- Service

- CN=Jane Doe/9874
- Rights: Can access file F1,
- Service S1,
- ...

- CN=Jane Doe

- X.509 Proxy
- Delegation

- S1

- F1

- Use delegated
- rights to access
- resources.

- X.509 Id
- certificate

- X.509 Proxy
- certificate

- Create

- Globus Security

- May 4, 2005

## Community Authorization Service

- Question: How does a large community grant its users access to a large set of resources?
- Community Authorization Service (CAS)
- Outsource policy admin to VO sub-domain
- Enables fine-grained policy
- Resource owner sets course-grained policy rules for foreign domain on “CAS-identity”
- CAS sets policy rules for its local users
- Requestors obtain capabilities from their local CAS that get enforced at the resource

- Globus Security

- May 4, 2005

## Community Authorization Service

**Domain A**

**Policy**

**Authority**

**Domain B**

**Sub-Domain A1**

**Sub-Domain B1**

**CAS identity**

**"trusted"**

**Requestor**

**Server**

**request +**

**CAS assertions**

**Virtual**

**Organization**

**Domain**

**capability**

**assertions**

**Community**

**Authorization Svc**

**enforcement**

**on CAS-identity and**

**requestor's capabilities**

- Globus Security

- May 4, 2005

## MyProxy:Credential Wallet/Converter

- MyProxy allows users to store GSI credentials and retrieve them
- With username/pass phrase or other credential
- Can act as a credential translator from username/passphrase to GSI
- Used by services that can only handle username and pass phrases to authenticate to Grid
- Services limited by client implementations
- E.g. web portals
- Also handle credential renewal for long-running tasks

- Globus Security

- May 4, 2005

## MyProxy - One-Time-Password

- MyProxy now supports SASL and PAM for authentication
- PAM plugins for one-time passwords (OTP) allow for bridging between OTP and Grid security
- User authenticates to MyProxy via OTP and gets short-term Grid credential in return

- Globus Security

- May 4, 2005

## Portal-based Grid Interface: PURSE

- Portal extensions (CGI scripts) that automate user registration requests.
- Solicits basic data from user.
- Generates cert request from CA (implemented with “simple CA” from GT).
- Admin interface allows CA admin to accept/reject request.
- Generates a certificate and stores in MyProxy service.
- Gives user ID/password for MyProxy.
- Benefits
- Users never have to deal with certificates.
- Portal can get user cert from MyProxy when needed.
- Database is populated with user data.
- This can be reused in other projects!

- Globus Security

- May 4, 2005

## Delegation Service

- Exposes delegated credentials as first class resource
- Allows for resource across multiple services
- E.g. multiple jobs, RFT requests
- Allows for explicit destruction and renewal

- Globus Security

- May 4, 2005

## Part 2 Outline

**2004: The year we lost control of the desktop**
**MyProxy/GridLogon, OTP/Smart-Cards, Secure-Password Protocols, Virtual Machines,...**
- Leverage Security Service Implementations
- OpenSSL, OpenSAML, Shibboleth, Permis, Sun’s XACML, CNRI’s Handle System, ... XKMS
- GT’s Authorization Processing Framework
- VOMS/Permis/X509/Shibboleth/SAML/Kerberos identity/attribute assertions
- XACML/SAML/CAS/Permis/ProxyCert/SPKI authorization assertions
- Futures and Conclusion

- Globus Security

- May 4, 2005

## 2004: The Year we lost Control of the Desktop

- Compromised accounts, trojans, sniffers, viruses...
**When** compromised ... not if...
- New paradigm:
- Try to raise bar ... arms race
- It’s about “Detection” and “Limit Consequences” of Compromise
- New emphasis:
- No more long-lived secrets with the user...
- MyProxy/GridLogon
- One-Time-Password & Secure Password protocols
- Virtual Machine Sandboxes

- Globus Security

- May 4, 2005

## MyProxy/GridLogon

- No long-lived secrets on the user’s workstation=> move secrets to a secure MyProxy-server
- Issue derived short-lived proxy-certificates
- 	=> issue short-lived identity certificates
- On-line Certificate Authority (CA)
- Need for bootstrap authentication...
- Passwords
- One-Time-Passwords
- Need for “true” secure password protocol

- Globus Security

- May 4, 2005

## OTP & Secure Password Protocol

- One-Time-Password “issues”
- Exchange in the clear - hijacking risk
- No mutual authentication
- Password authentication “issues”
- Off-line dictionary attacks
- Clear-text over SSL relies on server trust root on (untrusted) client
- Need for “true” secure password protocol
- Integrate OTP

- Globus Security

- May 4, 2005

## OTP & Trust-Root Provisioning

- OTP AuthN Server +
- user’s security config

*user-workstation*
*(initially  not configured)*

*Secure mutual OTP-Authentication *
*and Key-Exchange*

*Short-Lived Cert + *
*Provisioning of*
*CA’s, AuthZ/Attr Authorities*

*OTP*

- Enhanced MyProxy/GridLogon Svc

*Bootstrap User’s Trust-Root Config *
*from Secure OTP Authentication*

- Globus Security

- May 4, 2005

## Virtual Machines to the Rescue

- VM’s provide additional insulation
- Consequences of VM compromise “limited”
- Host compromise “virtually” impossible
- “Frozen” VM-Image of stable, tested, uncompromised OS+Services configuration
- Distribution of “safe” VM-images
- Allows for easy restart/resync after compromise
- Interesting open source VM-efforts: Xen
- Exciting & promising first results at ANL (Tim Freeman, Kate Keahey)

- Globus Security

- May 4, 2005

## How do Grids and VMs play toghether?

-                           Client

*VM EPR*

*inspect and manage*

*Create *
*VM image*

- VM Factory

-     VM Repository

- VM Manager

*create new VM image*

*Resource*

*VM*

*start program*

- Globus Security

- May 4, 2005

## Part 2 Outline

- 2004: The year we lost control of the desktop
- MyProxy/GridLogon, OTP/Smart-Cards, Secure-Password Protocols, Virtual Machines,...
**Leverage Security Service Implementations**
**OpenSSL, OpenSAML, Shibboleth, Sun’s XACML, Handle System, ... Permis, XKMS**
- GT’s Authorization Processing Framework
- VOMS/Permis/X509/Shibboleth/SAML/Kerberos identity/attribute assertions
- XACML/SAML/CAS/Permis/ProxyCert/SPKI authorization assertions
- Futures and Conclusion

- Globus Security

- May 4, 2005

## Leverage (Open Source) Security Service Implementations

- OpenSSL
- “native” Proxy Certificate support coming...(**thanks to OpenSSL hacker Richard Levitte and KTH!**)
- Internet2’s OpenSAML
- Part of GT - used by CAS/GridShib/AuthzCallout/...
- Internet2’s Shibboleth
- NSF funded GridShib project to “Grid-enable” Shibboleth
- Sun’s open source XACML effort
- Integrate sophisticated policy decision engine in the GT
- CNRI’s Handle System
- Leverage robust, secure, global naming system for resource/subject attribute bindings
- Futures: XKMS, XrML, Permis, ...

- Globus Security

- May 4, 2005

## GT - Shibboleth Integration

- NSF-funded “GridShib” Project
- http://grid.ncsa.uiuc.edu/GridShib/
- Leverage Shibboleth implementations and deployments
- Sophisticated, policy controlled attribute service
- Client-server interactions through WS-protocols
- (optionally) preserve pseudonymity of client
- GridShib code will become part of GT
- Transparent use of Shib servers in GT-runtime

- Globus Security

- May 4, 2005

## Eart Science Grid’s use of CAS-Assertions

**Password | Username**

**Username | UserDN**

**LFile | PFile**

**Group | Operation | LFile**

**UserDN | Group**

- MyProxy/GridLogon used for portal authentication

- MyProxy/GridLogon used for UserDN mapping

- Group membership assignment

- Access Policy expressed with groups, actions and logical file names

- Mapping of logical file names to physical file paths

**User with “UserDN” is allowed to invoke **
**“****Operation” on physical file “Pfile”**

**SAML Authorization Assertion**
**signed by PortalId**

- Globus Security

- May 4, 2005

## ESG External GridFTP Retrieval

**Portal**

**MyProxy**

**User**

**username**
**password**

**username**
**userDN**

**userDN**
**group**

**Group**
**Action**
**LFile**

**LFile**
**PFile**

**GridFTP Server**

**PFile**

**login**

**browse**

**policy enforcement**

**Login**
**Proxycert Issuance**

**PFile URL**
**+ authz assertion**

**gridftp access**
**GSI-creds**
**Portal authz assertion**

**“****CAS” policy enforcement**

- Globus Security

- May 4, 2005

## Earth System Grid’s use of CAS plumbing

- Globus’ Community Authorization System (CAS)
- Uses SAML Authorization Decision Assertions (based on OpenSAML)
- Earth System Grid (ESG) Portal Application
- Own dedicated authorization system
- Generates CAS-compliant Authz Assertions
- Reuse of the CAS-enabled GridFtp services
- Usage Pattern applicable to many more projects...

- Globus Security

- May 4, 2005

## Part 2 Outline

- 2004: The year we lost control of the desktop
- MyProxy/GridLogon, OTP/Smart-Cards, Secure-Password Protocols, Virtual Machines,...
- Leverage Security Service Implementations
- OpenSSL, OpenSAML, Shibboleth, Permis, Sun’s XACML, CNRI’s Handle System, ... XKMS
**GT’s Authorization Processing Framework**
**VOMS/Permis/X509/Shibboleth/SAML/Kerberos ****identity/attribute assertions**
**XACML/SAML/CAS/Permis/ProxyCert/SPKI ****authorization assertions**
- Futures and Conclusion

- Globus Security

- May 4, 2005

## Security Services with VO

- Globus Security

- May 4, 2005

## GT’s GGF’s Authorization Call-Out Support

- GGF’s OGSA-Authz WG: “Use of SAML for OGSA Authorization”
- Authorization service specification
- Extends SAML spec for use in WS-Grid
- Recently standardized by GGF
- Conformant call-out integrated in GT
- Transparently called through configuration
- Permis interoperability
- Ready for GT4!
- Futures...
- SAML2.0 compliance ... XACML2.0-SAML2.0 profile

- Globus Security

- May 4, 2005

## GT-XACML Integration

- eXtensible Access Control Markup Language (XACML)
- OASIS standard
- Open source implementations
- XACML: sophisticated policy language
- Globus Toolkit will ship with XACML runtime
- Integrated in every client and server build on GT
- Turned-on through configuration
- ...and we’re using the XACML-”model” for our Authz Processing Framework...
- ...can be called transparently from runtime and/or explicitly from application...

- Globus Security

- May 4, 2005

## GT’s Assertion Processing “Problem”

- VOMS/Permis/X509/Shibboleth/SAML/Kerberos identity/attribute assertions
- XACML/SAML/CAS/XCAP/Permis/ProxyCert authorization assertions
- Assertions can be pushed by client, pulled from service, or locally available
- Policy decision engines can be local and/or remote
- Delegation of Rights is required “feature” implemented through many different means
**GT-runtime has to mix and match all policy information and decisions in a consistent manner...**

- Globus Security

- May 4, 2005

## Basic Access Control Policy

- Can I have glass of lemonade?

- Bob’s policy:
- Alice is my friend and I’ll share my lemonade with her
- Mallory is not my friend and he can go #$%^&

- Sure, here is a glass

- Can I have glass of lemonade?

- No way, I don’t like you

- Globus Security

- May 4, 2005

## Basic Access Control Policy (2)

- Can I have glass of lemonade?

- Bob’s policy:
- Alice is my friend and I’ll share my lemonade with her
- Mallory is not my friend and he can go #$%^&

- Sure, here is a glass

- Can I have glass of lemonade?

- No way, I don’t like you

**Resource Owner decides!**
- (ultimate source of authority for access)

- Globus Security

- May 4, 2005

## Delegation of Rights (1)

- Globus Security

- May 4, 2005

## Delegation of Rights (2)

- Ivan’s policy:
- Carol is my friend and I’ll share my lemonade with her
- I’ll share my lemonade with any friend of Carol
- I don’t know any Bob...(?)

- Carol’s policy:
- Bob is my friend and I’ll share my lemonade with him

**Ivan likes Carol + Carol likes Bob**
**=> Ivan likes Bob**
- (non-normative delegation logic ;-) )

- Globus Security

- May 4, 2005

## Delegation of Rights (3)

- Request to invoke porttype/operation on ws-resource

- Ivan’s PermitPolicy: Subject.vo-role == “administrator”
- Ivan’s Attribute Assertion: Carol.vo-role = “administrator”
- Ivan has no policy applicable to Bob => NotApplicable

- Application Reply

- Can Bob’s request context invoke
- porttype/operation on my ws-resource?

- Permit

- Carol’s PermitPolicy:
- Subject.name == “Bob”

- Carol’s SAML-XACML Authz Svc EPR = Ext-PDP

- Ivan’s local XACML PDP

**Ivan delegates the rights **
**to administrate access**
**to Carol**

- Globus Security

- May 4, 2005

## Authz Processing Assumptions (1)

- All Policy Statements, PDPs and Authz-Decisions have Issuer associated with them
- “someone” has to take responsibility for statements and associated decisions
- Resource Owner is the Ultimate Authority
- Any statement/decision that can not be directly traced back to the owner is NotApplicable
- “traced back”: delegation chain that starts with owner
- Two different Policy Statements and Queries
- Admin Policy Statements
- Issuer states that certain admin-subject are allowed to administer the rights of certain access-subjects to invoke certain operations on certain resources.
- Access Policy Statements
- Issuer states that certain access-subject are allowed to invoke certain operations on certain resources.

- Globus Security

- May 4, 2005

## Authz Processing Assumptions (2)

- “Push-Pull” Equivalence
- Pushing authz-assertion and evaluating it locally renders same decision as evaluating the same policy statements remotely behind an external PDP
- Authz-Decisions are Policy Statements
- Folded over the request context
- Could optimize by only considering the attributes used to render a decision...
- If attributes don’t specify a “invocation context”, then only the invoker’s identity would suffice...
- Conservative: mandate that all request context’s attributes values are equal to the ones that rendered the decision.

- Globus Security

- May 4, 2005

## Attribute Collection Framework

- Globus Security

- May 4, 2005

## GT’s Authorization Processing Model (1)

- Use of a Policy Decision Point (PDP) abstraction that conceptually resembles the one defined for XACML.
- Normalized request context and decision format
- Modeled PDP as black box authorization decision oracle
- After validation, map all attribute assertions to XACML Request Context Attribute format
- Create mechanism-specific PDP instances for each authorization assertion and call-out service
- The end result is a set of PDP instances where the different mechanisms are abstracted behind the common PDP interface.

- Globus Security

- May 4, 2005

## GT’s Authorization Processing Model (2)

- The Master-PDP orchestrates the querying of each applicable PDP instance for authorization decisions.
- Pre-defined combination rules determine how the different results from the PDP instances are to be combined to yield a single decision.
- The Master-PDP is to find delegation decision chains by asking the individual PDP instances whether the issuer has delegated administrative rights to other subjects.
- the Master-PDP can determine authorization decisions based on delegated rights without explicit support from the native policy language evaluators.

- Globus Security

- May 4, 2005

## GT Authorization Framework (1)

- Globus Security

- May 4, 2005

## GT Authorization Framework (2)

**AAA**
**token**

- Globus Security

- May 4, 2005

## GT Authorization Framework (3)

- Globus Security

- May 4, 2005

## GT Authorization Framework (3)

- Master-PDP accessed all mechanism-specific PDPs through same Authz Query Interface
- SAML-XACML-2 profile
- Master PDP acts like XACML “Combinator”
- “Permit-Overrides” rules
- Negative permissions are evil...
- Delegation-chains found through exhaustive search
- ...with optimization to evaluate cheap decisions first...
- “Blacklist-PDPs” are consulted separately
- Statically configured, call-out only PDPs
- Deny-Overrides only for the blacklist-PDPs...
- Pragmatic compromise to keep admin simple

- Globus Security

- May 4, 2005

## Big Picture & Conclusion

- GT4 is security buzzword compliant!
- ...probably the most security-full-featured ws-toolkit...
- Web Services technologies are providing the low-level plumbing
-  following all relevant standards
- Portals growing as a user interface
- Clients use http, ... but portals will use WS-protocols!
- PURSE, ESG, ...
- New Deployment Paradigms (GridLogon, VMs)
- Driven by inability to protect...
- Authorization still the big focus
- “unification framework” needed to support different mechanisms and formats

- Globus Security

- May 4, 2005