Shibboleth and PKI

1
Shibboleth and PKI

• Scott Cantor (cantor.2_at_osu.edu)
• April 10, 2003

2
The Blind Man and the Elephant

• How does Shibboleth work with PKI?
• Possible Answers
• It is a PKI.
• It can use a PKI for local authentication.
• It can use a PKI for authentication to a target.
• It can use a certificate in place of a handle.
• It can use a certificate as a hinting mechanism,
  or introduction vehicle.
• Shibboleth/SAML just reinvent PKI, so forget them.

3
PK(i) You Cant Avoid

• Shibboleth components, in the context of a
  federation, need to authenticate each other.
• Shibboleth could in theory use a variety of
  technologies (e.g. Kerberos), but in practice
  uses signatures and TLS authentication with X.509
  certificates and RSA keys.
• How many are there?

4
High Level ArchitectureKnock, Knock
5
PK(i) You Cant Avoid

• Currently a mix of code and libraries performing
  traditional certificate path validation using
  CA root lists via OpenSSLs built-in
  verification.
• Specifics of InCommons trust infrastructure are
  yet to be finalized.

6
PKI You Can Avoid(if you want to)

• There are no dependencies on PKI as a user
  authentication mechanism, but no specific
  constraints either.
• We believe that most of the common use cases
  will be met by version 1.0.
• There are three different points of user contact
  defined, any of which could accept a certificate
  from a user agent.

7
Handle Service(Local Authentication)

• There are no requirements about user
  authentication, therefore client certificates are
  perfectly valid as a local choice.
• In the supported configuration, relies on mod_ssl
  to accept and validate the certificate.
• A Java filter is provided (since 0.8) to
  manipulate the contents into a principal name for
  use by the HS.

8
Local Authentication via X.509What does it mean
to a target?

• Version 1.0 will include an origin property for
  SAML AuthenticationMethod element.
• Asserts the technology used for authentication,
  but not the strength, nor anything about
  initial identification or CPS.
• Addressed in more depth by Liberty Alliance
  specification as AuthenticationContext.
• Has no effect on the subsequent security of
  Shibboleth from the targets perspective.

9
Remote Authentication to Target(Not Implemented
Yet)

• User agent could also present certificate
  directly to target resource.
• Certificate might or might not be personally
  identifying.
• Target might or might not validate certificate in
  any usual sense (but origin would).
• Bypasses WAYF and HS functions.

10
Attribute Exchange and Trust Implications

• Attribute exchange and subsequent authorization
  is largely the same, or its not really
  Shibboleth anymore.
• SHAR needs a handle (the certificate) and an AA
  (not well-defined yet).
• Resembles the DLF access control prototype
  utilizing HTTP/LDAP callback.

11
WAYF? I just told you.(Also Not Implemented)

• Typical WAYF can remember users choice of origin
  once selected, but has a harder time
  forgetting.
• An otherwise worthless certificate could tell the
  WAYF (or a target) where to send the user for
  authentication.
• Multiple certificates could act as
  user-selectable routing instructions.

12
Summary

• Clarity in discussions is important.
• Any time a browser accesses a web server, a
  certificate might serve some purpose, but only
  local authentication is understood or
  supported.
• Connection between a federations trust
  infrastructure and an authentication PKI seems
  tenuous.