The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

IdP Infocard Discussion

Owned by Former user (Deleted)
Last updated: Apr 24, 2009Version comment
2 min read

Infocard issues and choices at the IdP

Bindings

Infocard allows both transport and symmetric binding. The former uses the transport (https) to secure messages; the latter uses shared secrets.

We chose transport binding because it apears to be more common, and is easier to implement.

Authn mechanism

Infocard supports several authn mechanisms:

  • username and password.
  • kerberos
  • X509 certificate
  • self-issued token

We implement the username/password because it's the most common way people use SSO. It's easiest to implement, and works for everyone.

We also implement the self-issued token because it's popular, at least with testers - and convenient for users.

Do not support Kerberos.

Do not support Certificates.

Attributes

On the card

The card lists all the attributes it can provide.

We allow this list to be specified in the IP's relying-party.xml configuration. Multiple types of cards could be issued by configuring multiple infocard profile configurations and endpints. This could certainly bring up UI issues. How would users distinguish and keep track of multiple cards?

One simple solution is to list on the card all possible attributes supported by the IP.

At card use

An assertion request lists all the claims (attributes) desired by the RP. It is not determined whether or not the IP actually has to provide an attribute for each claim or can leave out some.

The infocard model allows a user to decide whether or not to release information to the RP, so we use a single ARP for the infocard system as a whole - basically releasing any information. Alternativley, we could use an ARP based on the RP's identity.

The assertion part of the response is encrypted and thus unreadable by the IS. Part of the response to the IS contains display values for each attribute. We set these displays to the actual values.

RP Identity

The IP needs the identity (entityID) of the RP for several reasons:

  • encryption of the response
  • possible filtering of attributes
  • possible audit needs
  • others

What the IP normally gets in a request is a location, the url that triggered login, although requests can contain something more like an entity id.

Requests can also include the RP's certificate. Normally they do not.

If we get an RP's endpoint reference we use that as an entityID to looks up metadata for the RP. Otherwise we form an entityID from the domain of the location. e.g. 'https://example.com/photos/vacation/..' becomes 'https://example.com/'

If we get a certificate with the request we use it to encrypt the response. Otherwise, if the RP's metadata is found we use the certificate from that. As a last resort, we make an https GET request to the generated entityID and use the certificate used by the RP's site.

Card image

Infocard allows the card issuer to specify an image for the card. It is an obvious place for some customization for each user or type of card. However, any text on the card has to be a part of the image. We allow a system call to a configured image generation program that returns the image.