On conventions for passing IdP identifiers in Bamboo Ecosystem

Where are IdP identifiers used?

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:

1. An IdP identifier is a component of the so-called SourcedId used as an input parameter to the Bamboo Person Service (cf. Person API on the Bamboo wiki archive hosted at UCB). 
   1. When constructing a SourcedId, clients are assumed to assert ONLY the IdP used to authenticate in the current session (the session within which a request to BSP is made)
   2. A client may assert any string as SourcedId.
   3. However, consistency is of paramount functional importance, such that an IdP is identified in the same way whenever a SourcedId is communicated to the BSP
   4. Consistency across multiple clients is necessary: this is what permits different client applications to match the correct BPId to a user no matter what application s/he uses to authenticate. [Consider the Account Services module, which in its final form is intended to establish Bamboo Persons and associations between these and the single or multiple identity providers to which a user chooses to authenticate; once established, other clients of BSP (e.g., Research Environments) expect to be able to pass a SourcedId associated with an established Bamboo Person to the BSP in order to obtain the authenticated user's pre-existing BPId.]
2. An IdP identifier may be asserted as an element of a scoped role passed in the X-Bamboo-Roles header of any request to the BSP made by a trusted client application
   1. The a scoped role format is assumed to be role@domain
   2. In the "interim" solution (short of N-tier), the only meaningful role that may be asserted with respect to an institution is affiliation, i.e., that the authenticated user is affiliated with an institution represented by the domain part of the scoped role; this affiliation is inferred from the user's ability to authenticate to the institution's IdP.
3. An IdP identifier may be asserted in a Policy that, for example, permits access to users who have any of a set of permitted scoped roles where the set of scoped roles represents institutional affiliations (e.g., affiliates of Berkeley, Wisconsin, and Tufts may access resources governed by this policy). Cf. Authorization and Policy for more detailed discussion.

Why is a convention needed?

1. ScopedId values passed by different authenticating clients want to assert the same ScopedId value for any given user authenticating at a given IdP. That is, Professor Jones authenticating to Acme University should be represented by the same SourcedId whether she has authenticated through Research Environment XYZ, Research Environment ABC, or the standalone Account Services Module.
2. Affiliation asserted by a client in the form of a scoped role must match a scoped role allowed by a policy in order to successfully "pass" the policy's rule. Clients must either
   1. know how affiliations are represented differently in the policies associated with various services to which the client directs request on an authenticated user's behalf (so that they can construct scoped roles appropriately for a given request); or,
   2. know how affiliations are represented conventionally in policies that apply to all services governed by BSP policies (so that they can assert affiliation in each request without needing to be aware of policies that may govern the resource being requested)
   3. b is easier for the client developer(s) than a!

What should the convention be (a modest proposal)?

A user's fine-grained (detailed type of) affiliation is unknown in the interim 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, a modest proposal would be to use the convention undefined@domain to represent user affiliation inferred from the IdP used to authenticate in the current session.

Examples in scoped role format:

• undefined@berkeley.edu
• undefined@wisc.edu
• undefined@google.com 

Examples in IdPId format:

• http://berkeley.edu
• http://wisc.edu
• http://google.com

QUESTION to Keith: is there a better convention for IdPId format that corresponds to the value of some SAML attribute that is always returned by an authenticating IdP?

What else needs to be said?

???