Globus Security with SAML, Shibboleth, and GridShib

1
Globus Securitywith SAML, Shibboleth, and
GridShib

• 230pm, May 4, Faculty Club, UCSD
• GT4 Tutorial, May 3-4, 2005, San Diego
• Frank Siebenlist - Argonne National Laboratory
• (franks_at_mcs.anl.gov)
• http//www.globus.org/

2
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)

3
Outline

• SAML Introduction
• Shibboleth Introduction
• GridShib Introduction
• Globus Security

4
SAML
5
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)

6
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

7
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

8
SSO use case
9
Authorization service use case
10
Back office transaction use case
11
Whats needed

• A standard XML message format
• Its 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

12
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

13
SAML in a nutshell

• Its 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
• Its an OASIS standard (1.0, 1.1 and 2.0)
• Vendors and users are involved
• Codifies current system outputs rather than
  inventing new technology

14
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

15
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

16
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

17
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

18
Example authentication assertion

• ltsamlAssertion MajorVersion1
  MinorVersion0 AssertionID128.9.167.32.12345
  678 IssuerSmith Corporation
  IssueInstant2001-12-03T100200Zgt
  ltsamlConditions NotBefore2001-12-03T10000
  0Z NotAfter2001-12-03T100500Z /gt
  ltsamlAuthenticationStatement
  AuthenticationMethodpassword
  AuthenticationInstant2001-12-03T100200Zgt
  ltsamlSubjectgt ltsamlNameIdentifier
  SecurityDomainsmithco.com
  Namejoeuser /gt lt/samlSubjectgt
  lt/samlAuthenticationStatementgt lt/samlAssertiongt

19
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

20
Example attribute assertion

• ltsamlAssertion gt ltsamlConditions /gt
  ltsamlAttributeStatementgt ltsamlSubjectgt
  ltsamlNameIdentifier SecurityDomainsmit
  hco.com Namejoeuser /gt
  lt/samlSubjectgt ltsamlAttribute
  AttributeNamePaidStatus
  AttributeNamespacehttp//smithco.comgt
  ltsamlAttributeValuegt PaidUp
  lt/samlAttributeValuegt lt/samlAttributegt
  lt/samlAttributeStatementgtlt/samlAssertiongt

21
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

22
Example authorization decision assertion

• ltsamlAssertion gt ltsamlConditions /gt
  ltsamlAuthorizationStatement
  DecisionPermit Resourcehttp//jonesco.com
  /rpt_12345.htmgt ltsamlSubjectgt
  ltsamlNameIdentifier SecurityDomainsmith
  co.com Namejoeuser /gt
  lt/samlSubjectgt lt/samlAuthorizationStatementgtlt
  /samlAssertiongt

23
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

24
SAML protocol for getting assertions
25
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

26
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

27
Example authentication assertion request

• ltsamlpRequest MajorVersion1
  MinorVersion0 RequestID128.14.234.20.123456
  78 gt ltsamlpAuthenticationQuerygt
  ltsamlSubjectgt ltsamlNameIdentifier
  SecurityDomainsmithco.com
  Namejoeuser /gt lt/samlSubjectgt
  lt/samlpAuthenticationQuerygtlt/samlpRequestgt

28
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

29
Example attribute assertion request

• ltsamlpRequest gt ltsamlpAttributeQuery
  CompletenessSpecifierPartialgt
  ltsamlSubjectgt ltsamlNameIdentifier
  SecurityDomainsmithco.com
  Namejoeuser /gt lt/samlSubjectgt
  ltsamlAttributeDesignator
  AttributeNamePaidStatus
  AttributeNamespacehttp//smithco.comgt
  lt/samlAttributeDesignatorgt lt/samlpAttributeQue
  rygtlt/samlpRequestgt

30
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

31
Example authorization decision assertion request

• ltsamlpRequest gt ltsamlpAuthorizationQuery
  Resourcehttp//jonesco.com/rpt_12345.htmgt
  ltsamlSubjectgt ltsamlNameIdentifier
  SecurityDomainsmithco.com
  Namejoeuser /gt lt/samlSubjectgt
  ltsamlActions Namespacehttp//gt
  ltsamlActiongtReadlt/samlActiongt
  lt/samlActionsgt ltsamlEvidencegt
  ltsamlAssertiongt some assertion
  lt/samlAssertiongt lt/samlEvidencegt
  lt/samlpAuthorizationQuerygtlt/samlpRequestgt

32
Example response

• ltsamlpResponse MajorVersion1
  MinorVersion0 RequestID128.14.234.20.901234
  56 InResponseTo128.14.234.20.12345678
  StatusCodeSuccessgt ltsamlAssertion
  MajorVersion1 MinorVersion0
  AssertionID128.9.167.32.12345678
  IssuerSmith Corporation"gt ltsamlConditions
  NotBefore2001-12-03T100000Z
  NotAfter2001-12-03T100500Z /gt
  ltsamlAuthenticationStatement gt
  lt/samlAuthenticationStatementgt
  lt/samlAssertiongtlt/samlpRequestgt

33
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

34
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

35
The SOAP-over-HTTP binding
36
By contrast, the SOAP profile
37
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

38
Back office transaction scenario
39
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

40
SAML Agenda

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

41
SAML Standards History
LA Liberty Alliance ID-FF
Identity Federation Framework
SAML Security Assertion Markup
LanguageXACML Extensible Access Control Markup
Language
Formally submitted to the SSTC
SAML 2.0Q1/2005
ID-FF 1.2October 2003
LA 1.1January 2003
XACML 2.0Q1/2005
Shibboleth1H03
SAML 1.1May 2003
WSS SAML Token Profile Q4/04
WSS SOAP Security Q4/03
SAML 1.0May 2002
XACML1.0February 2003
42
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

43
Specification Actors and Topics
UserClients
UserClients
IdentityProvider Session AuthorityAttributePr
ovider
Service ProviderSessionParticipant Attribute
Consumer
Metadata
SessionMngmt
AttributeServices
SSO
IdentityFederation
Trust Relationship
AttributeProvider
AttributeConsumer
Specification Topics
Actors
Actors
44
Agenda

• SAML 2.0 Overview
• SAML 2.0 Feature Set
• Federation Models in SAML 2.0
• Conclusion

45
SAML 2.0 Feature Set

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

46
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)

47
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

48
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

49
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 SPs
• In some cases may require bulk update or
  synchronization of parts of the user store at
  both ends

50
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

51
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

52
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

53
Name Identifier Management

• Protocol for communicating information about name
  identifiers
• When identifiers should be updated
• Replace jsmith_at_foo.com by johns_at_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_at_foo.com
• SP will not accept assertions for jsmith_at_foo.com

54
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

55
SAML 2.0 Feature Set

• Overview
• SSO
• Identity Federation
• Sessions and Logout
• Attribute Services
• Metadata

56
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

57
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

58
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

59
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

60
Shibboleth
61
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)

62
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

63
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

64
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 Xs
  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.

65
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

66
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

67
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

68
The Architecture of Shibboleth
69
High Level ArchitectureKnock, Knock
70
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

71
Key Concepts

• SAML
• Attributes in an Inter-Realm Context
• Metadata and ProviderIDs
• Credentials and Relying Parties
• Attribute Release Policies (ARPs)
• Attribute Acceptance Policies (AAPs)

72
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

73
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

74
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?

75
LDAP to SAML as performed by AA

• LDAP
• objectclass eduPerson
• dn uidmagneto, oupeople, dcsupervillain,
  dcedu
• eduPersonAffiliation staff
• SAML
• ltAttribute
• AttributeName"urnmacedirattribute-defeduPe
  rsonScopedAffiliation"
• AttributeNamespace"urnmaceshibboleth1.0att
  ributeNamespaceuri"gt
• ltAttributeValue Scopesupervillain.edu"gt
• staff
• lt/AttributeValuegt
• lt/Attributegt

76
Metadata and ProviderIDs

• A ProviderID is the basic atom of inter-realm
  policy and trust the molecule is the enterprise
• URI (urnmaceinqueuesupervillain.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

77
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

78
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-bas
  ed matches supports both positive and negative
  attribute rules

79
ARP Example

• ltRulegt
• ltTargetgt
• ltAnyTarget/gt
• lt/Targetgt
• ltAttribute nameurnmacedirattribute-defeduPer
  sonScopedAffiliationgt
• ltAnyValue releasepermit/gt
• lt/Attributegt
• lt/Rulegt

80
Shib Deployment Resources

• http//shibboleth.internet2.edu
• http//inqueue.internet2.edu
• Origin
• http//shibboleth.internet2.edu/guides/deploy-guid
  e-origin-1.2.1.html
• http//shibboleth.internet2.edu/guides/identity-pr
  ovider-checklist.html
• Target
• http//shibboleth.internet2.edu/guides/deploy-guid
  e-target-1.2.1.html
• shibboleth-users_at_internet2.edu

81
GridShib
82
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

83
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 elses will be writing and
  deploying them
• SAML standard, profiles
• Leverage someone elses attributes?
• Are campus attributes useful to Grids?

84
Outline

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

85
Shibboleth Federation Model
Attrs
Attrs
SAML
IDs
IDs
86
Shibboleth (Simplified)
SAML
Shibboleth
Attrs
Attributes
Handle
WWW
IDs
Handle
87
GridShib (Simplified)
SAML
Shibboleth
Attrs
Attributes
DN
Grid
IDs
DN
SSL/TLS, WS-Security
DN
88
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

89
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

90
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 dont have resources to run a 7x24
  security service, but are the only ones who know
  the attribute space
• Explore Signet, Grouper

91
Distributed Authorities
Session authentication credential
Attribute Authority
Authorities
Home Org
Affiliated Org
Grid Service
Virtual Org
92
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
• Dont require modification to typical grid client
  applications for simple use cases
• Most of work going into Grid services

93
GirShib Questions?

• Project website
• http//grid.ncsa.uiuc.edu/GridShib/
• For more information on NMI
• http//www.nsf-middleware.org/

94
Globus Security
95
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
• GTs Authorization Processing Framework
• Futures and Conclusion

96
Security Services Objectives

• Its all about Policy
• (Virtual) Organizations 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

97
Agreement ? VO Security Policy
(Business) Agreement
Dynamic VO Security Policy
Price Cost Obligations QoS TCs Security

members resources roles Attribute mgmt Authz
mgmt
Static Initial VO Security Policy
trust anchors (initial) members (initial)
resources (initial) roles Access rules Privacy
rules
98
Virtual Organization Concept
99
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?

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

101
Controlled Resource Sharing

• Globally
• User must agreeto AUP
• User must use strong authentication

ComputeCenter
20 Mbytes/sec max
BIO VO
5pm-9amonly
HEP VO
100 Tbytes max
20 Tflops per month max
Chem EngVO
102
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

103
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).
• Doesnt allow for static configuration

104
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

105
Multi-Institution Issues
Certification
Certification
Authority
Authority
Domain B
Domain A
Policy
Policy
Authority
Authority
Task
Server Y
Server X
Sub-Domain A1
Sub-Domain B1
106
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
• Cant 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

107
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!

108
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

109
Grid SolutionUse Virtual Organization as Bridge
No Cross- Domain Trust
Certification
Domain A
Federation
Service
GSI
Virtual
Organization
Domain
110
Effective Policy GoverningAccess Within A
Collaboration
111
Use Delegation toEstablish Dynamic Distributed
System
ComputeCenter
Service
Rights
VO
ComputeCenter
112
Goal is to do this with arbitrary mechanisms
ComputeCenter
X.509AC
X.509/SSL
SAMLAttribute
X.509AC
Kerberos/ WS-Security
Rights
VO
ComputeCenter
SAMLAttribute
113
Security ofGrid 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

114
Propagation of Requesters Rights through Job
Scheduling and Submission Process
Virtualization complicates Least Privilege
Delegation of Rights
Dynamically limit the Delegated Rights more as
Job specifics become clear
Trust parties downstream to limit rights for
youor let them come back with job specifics
such that you can limit them
115
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.

116
Security Layers
Grid-Mapfile/SAML/XACML
Authorization
X.509 Proxy Certificates/SAML/XACML
Delegation
Authentication
X.509 ID Certificates
Message Protection
WS-Security/WS-SecureConversation
Message Format
SOAP
117
Grid Security Infrastructure (GSI)

• Use GSI as a standard mechanism for bridging
  disparate security mechanisms
• Doesnt solve trust problem, but now things talk
  same protocol and understand each others
  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

118
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

119
Grid Identity, Local Policy
Map tolocal name

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

Grid Identity
LocalPolicy
Map tolocal name
LocalPolicy
120
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.

121
Local Identity,Grid Identity, Local Policy
KCA
Map tolocal name
Grid Identity
KerberosSite
LocalPolicy
SSLK5
KRB5 Resources
122
GSI Implementation
Services (running on users behalf)
Authz Callout
Access
ComputeCenter
Rights
VOUsers
Rights
VO
MyProxy
Rights
KCA
123
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

124
Proxy Certificates
Create
F1
Service
CNJane Doe
CNJane Doe/9874 Rights Can access file
F1, Service S1,
X.509 Proxy Delegation
Use delegated rights to access resources.
X.509 Id certificate
X.509 Proxy certificate
S1
125
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

126
Community Authorization Service
Domain A
Domain B
Sub-Domain B1
Sub-Domain A1
Policy
Authority
Community
Authorization Svc
enforcement
CAS identity
on CAS-identity and
"trusted"
requestor's capabilities
capability
assertions
request
CAS assertions
Server
Requestor
Virtual
Organization
Domain
127
MyProxyCredential 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

128
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

129
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!

130
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

131
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, Suns
  XACML, CNRIs Handle System, XKMS
• GTs Authorization Processing Framework
• VOMS/Permis/X509/Shibboleth/SAML/Kerberos
  identity/attribute assertions
• XACML/SAML/CAS/Permis/ProxyCert/SPKI
  authorization assertions
• Futures and Conclusion

132
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
• Its 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

133
MyProxy/GridLogon

• No long-lived secrets on the users
  workstationgt move secrets to a secure
  MyProxy-server
• Issue derived short-lived proxy-certificates
• gt issue short-lived identity certificates
• On-line Certificate Authority (CA)
• Need for bootstrap authentication
• Passwords
• One-Time-Passwords
• Need for true secure password protocol

134
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

135
OTP Trust-Root Provisioning
Bootstrap Users Trust-Root Config from Secure
OTP Authentication
Enhanced MyProxy/GridLogon Svc
Secure mutual OTP-Authentication and Key-Exchange
OTP AuthN Server users security config
Short-Lived Cert Provisioning of CAs,
AuthZ/Attr Authorities
OTP
user-workstation (initially not configured)
136
Virtual Machines to the Rescue

• VMs provide additional insulation
• Consequences of VM compromise limited
• Host compromise virtually impossible
• Frozen VM-Image of stable, tested,
  uncompromised OSServices 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)

137
How do Grids and VMs play toghether?
VM Factory
create new VM image
VM EPR
Create VM image
VM Repository
inspect and manage
Client

Resource
VM Manager
VM
start program
138
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, Suns XACML,
  Handle System, Permis, XKMS
• GTs Authorization Processing Framework
• VOMS/Permis/X509/Shibboleth/SAML/Kerberos
  identity/attribute assertions
• XACML/SAML/CAS/Permis/ProxyCert/SPKI
  authorization assertions
• Futures and Conclusion

139
Leverage (Open Source) Security Service
Implementations

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

140
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

141
Eart Science Grids use of CAS-Assertions
MyProxy/GridLogon used for portal authentication
Password Username
MyProxy/GridLogon used for UserDN mapping
Username UserDN
Group membership assignment
UserDN Group
Access Policy expressed with groups, actions and
logical file names
Group Operation LFile
Mapping of logical file names to physical file
paths
LFile PFile
SAML Authorization Assertion signed by PortalId
User with UserDN is allowed to invoke
Operation on physical file Pfile
142
ESG External GridFTP Retrieval
username password
username userDN
MyProxy
userDN group
Group Action LFile
LFile PFile
PFile
GridFTP Server
Portal
CAS policy enforcement
Login Proxycert Issuance
policy enforcement
gridftp access GSI-creds Portal authz assertion
login
PFile URL authz assertion
browse
User
143
Earth System Grids 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

144
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, Suns
  XACML, CNRIs Handle System, XKMS
• GTs Authorization Processing Framework
• VOMS/Permis/X509/Shibboleth/SAML/Kerberos
  identity/attribute assertions
• XACML/SAML/CAS/Permis/ProxyCert/SPKI
  authorization assertions
• Futures and Conclusion

145
Security Services with VO
146
GTs GGFs Authorization Call-Out Support

• GGFs 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

147
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 were using the XACML-model for our Authz
  Processing Framework
• can be called transparently from runtime and/or
  explicitly from application

148
GTs 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

149
Basic Access Control Policy
Bobs policy Alice is my friend and Ill share
my lemonade with her Mallory is not my friend and
he can go
Can I have glass of lemonade?
Sure, here is a glass
Can I have glass of lemonade?
No way, I dont like you
150
Basic Access Control Policy (2)
Bobs policy Alice is my friend and Ill share
my lemonade with her Mallory is not my friend and
he can go
Can I have glass of lemonade?
Sure, here is a glass
Resource Owner decides! (ultimate source of
authority for access)
Can I have glass of lemonade?
No way, I dont like you
151
Delegation of Rights (1)
152
Delegation of Rights (2)
Ivans policy Carol is my