This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.
Project Bamboo's current (as of April 2013) IAM implementation is predicated on trusted client applications authenticating users, and asserting attributes about authenticated users to the Bamboo Services Platform when making service requests. Cf. the Bamboo IAM from a client application's perspective section of Identity and Access Management - Authentication and Authorization for both broader context and specific details.
One critical attribute of authenticated users is a reference to the Identity Provider (IdP) used to authenticate her/him. This information is asserted about a user by the client application in three distinct but interdependent contexts, enumerated below. In order for the IAM mechanism as a whole to function properly, all clients must represent IdPs to which users authenticate uniformly when associating user identities with login events.
Details about why these conventions are essential, and recommendation for standard representations to be used, are described on this page. It is worth noting that this convention is dependent upon proper (conventional) configuration of a Social/SAML gateway for social media identity providers (such as Google), as described on the page Social/SAML Gateway to enable social media identity provision.
Identity providers authenticate users in the Bamboo Trust Federation. Trusted client applications are responsible for requiring and managing execution of authentication. In general, they do so by operating as a Shibboleth SP (Service Provider).
The identity provider used to authenticate a user in a given session is communicated or used in the following ways:
A user's fine-grained (detailed type of) affiliation is unknown in the currently-implemented IAM solution used by Bamboo, which does NOT rely on N-tier authentication and therefore does not pass fine-grained user attributes that may be asserted by an IdP.
A user's role at the institution running the IdP at which a user authenticated is therefore undefined.
Therefore, the recommendation is to use the convention undefined@domain to represent user affiliation inferred from the IdP used to authenticate in the current session.
Examples of user affiliation in scoped role format:
Examples of Identity Provider identifiers in IdPID format:
Client applications are responsible for extracting the conventionally-represented IdP identifier from attributes available to it following successful user authentication. As in the examples above, the appropriate string is expected to be the top-level domain and its immediate subdomain.
This string must be extracted by a client tool, application, or service from the Apache httpd environment variable Shib-Identity-Provider available to the client on successful user authentication. This environment variable is available to a client because such clients are required to act as a Shibbloleth Service Provider.
For example, a client would extract wisc.edu from the Shib-Identity-Provider value.
As details of parsing and manipulating strings are particular to a given client's implementation language or platform, this documentation does not suggest how a client is to meet the responsibility for extracting the domain (such as berkeley.edu) and (depending on the context) either prepending http:// or undefined@ to construct the IdP identifier.