Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Shibbolethandsamlnotes

Shibbolethandsamlnotes

Rob's Notes About Shibboleth and SAML

Rob's Notes About Shibboleth and SAML

Shibboleth

Shibboleth allows users to securely send trusted information about themselves to remote resources. This information may then be used for authentication, authorization, content personalization, and enabling single sign-on across a broad range of services from many different providers.

  • Main actors/actions
    • Source: https://spaces.internet2.edu/display/SHIB2/FlowsAndConfig
    • User
    • IdP - identity provider. This would be like a naming authority in GENI
    • SP - service provider. The entity offering a service the user wishes to use - this would be like a CM or other implementor of a GENI API
    • Basic idea: User goes to SP, is redirected to IdP to log in, and IdP communicates information about the user, subject to policy, to the SP, which then considers the user to be logged in
  • Mostly about web services ad "Single Sign On"
  • Uses SAML underneath
  • Allows semi-anonymity in that you can choose to identify the home institution, but not the user themselves
  • Downsides from a GENI perspective
    • Online: The IdP has to communicate with the SP to provide authentication information
    • It's about authenticating specific sessions (ie. "logging in") rather than establishing long-term identity. None of the GENI scenarios I've seen involve logging in to the name repository in order to gain access to a CM.
    • Example text and use cases seem to assume that the goal of federation is to unify several existing identities (ie. accounts belonging to the same users on many different systems. (The following text actually comes from the SAML FAQ)

What is federated identity?

Federated identity allows a set of service providers to agree on a way to refer to a single user, even if that user is known to the providers in different guises. Most commonly, federated identity is achieved through the linking together of the user's several accounts with the providers. This allows the user to get more personalized service without centrally storing personal information. Also, it gives the user fine control over when and how their accounts and attributes are linked and shared, allowing for greater control over their personal data. In practice, this means that users can be authenticated by one company or web site and be recognized and delivered personalized content and services in other locations without having to re-authenticate or sign on with a separate username and password.

SAML Notes

  • Sources of reading material
  • Key things in SAML
    • assertion - one or more statements made by an authority (signed, verifiable)
      • authentication - "I have authenticated entity X using method Y at time Z"
      • attribute - just a set of key/value pairs giving more information about the entity
      • authorization decision - some decision that has been made about whether the entity has been allowed or denied access to some resource
    • protocol - wire format for queries and responses regarding assertions
    • binding - mappings of SAML protocols to lower-level transport such as SOAP or HTTP
    • profile - definition of how SAML will be used for some specific application
    • attribute profile - rules for interpreting attribute assertions (ie. the meanings of fields in a certificate)
  • (never mind...) Possible reason for not using SAML - seems to assume authenticating entity (which would be something like a CM in our case) will always talk to the identity provider (ie. authority) in real-time to do authentication

The most important type of SAML protocol request is called a query. A service provider makes a query directly to an identity provider over a secure back channel. Thus query messages are typically bound to SOAP.

  • On further reading, I'm not sure that such a query is actually required for authentication, so it may not have to be online
  • SAML has been designed for some specific use cases - whether or not it's appropriate for us to use is probably dependent on whether we think we match any of the use cases
  • Downsides from a GENI perspective (these would generally apply to Shibboleth as well, I think, since it;s based on SAML)
    • Seems to take a different approach to Federation than has been discussed in GENI so far - this is not to say that this model won't work for GENI, but it would be a change from the architecture thus far. See quote included above in Shibboleth section.
    • Like Shibboleth, seems to be about authenticating individual sessions rather than long-term identity establishment
    • Doesn't seem to support the sort of hierarchy of naming authorities that GENI has proposed
    • Not clear whether it is good at handling highly-dynamic federation (as opposed to a small number of federates with basically hardcoded relationships)
  • Nice properties
    • Has a style that feels more "traditional" than what's currently in the GENI architecture
    • The general idea of signing assertions about an entity is a good one
    • Authorization Decision assertions *might* be useful for credentials, but it's not clear SAML allows them to be separated from authentication sessions (ie. to indicate a long-lived permission)