Authentication Service Description and Assumptions

Unknown macro: {multi-excerpt} Authentication service is a security service that verifies an identity claimed by or for a system entity.

Unknown macro: {multi-excerpt}

A system entity is an active element of a system, e.g. an automated process, a subsystem, a person or group of persons that incorporates a specific set of capabilities.

A Person is a system entity, usually a human individual, that makes use of system resources, primarily for application purposes as opposed to system management purposes.

An Agent is a non-human system entity.

Unknown macro: {multi-excerpt}

Relationships

Following describes the relationship between a Principal, Person and an Agent.

• A Subject could represent a Person or an Agent (system or process or service within a system).
• A Person may have multiple identities each valid in different contexts, e.g. a person may be a staff member and a student. Each context would have different access levels. The same applies to agent as well (e.g. identity with public key, identity with username/password, etc.)
• Therefore, a Subject may have one or more identities, i.e. one or more principals.
• Each Subject could have one or more identity attributes.

Authentication process

The Authentication process is the process of verifying an identity claimed by or for a system entity. It consists of two steps :

1. Identification step: Presenting an identifier to the security system.
2. Verification step: Presenting or generating authentication information that corroborates the binding between the entity and the identifier.

Let's describe a typical authentication scenario using widely used security terms. Following are our assumptions.

Assumptions

1. A system entity (e.g. a user with Berkeley CalNet ID) has/is already enrolled with at least one identity provider (e.g. CalNet).
2. System entity could be human or non-human.
3. An identity provider is expected to provide authentication services.
4. How the enrollment or signup with the identity provider happens is out of scope for the Authentication Service. It could be part of registration or account set up process of CollectionSpace or elsewhere.
5. A service provider (or relying party, e.g. a CollectionSpace service) relies on the identity provider to identify and verify the identity of the system entity
6. A service provider could rely on one or more such identity provider for authentication services.

Unknown macro: {multi-excerpt}

At a very high level, the authentication process is carried out as follows in CollectionSpace:

1. Bob (e.g. a person in the role of "Collections Manager" at hearstmuseum.berkeley.edu) tries to login to CollectionSpace (service(s)) using a web-based user interface.
2. CollectionSpace service redirects Bob to an identity provider (e.g. CalNet IdM).
3. The identity provider asks for credentials from Bob and verifies his identity.
4. At Bob's request, the identity provider passes an assertion to the CollectionSpace service. Note that the identity provider might explicitly ask Bob for the permission to do so or it might implicitly pass the assertion based on prior agreement with Bob. Details on how this is achieved is out of scope for the CollectionSpace Authentication Service.
5. On the basis of this assertion, CollectionSpace makes access control decisions for the CollectionSpace resources accessed by Bob.

Unknown macro: {multi-excerpt}

Issue: How to choose identity provider(s) at the time of login with multi-tenant deployment?

While, the issue of selecting identity provider(s) may not be a critical question for any single tenant system, it is a critical question for a multi-tenant system. A multi-tenant system could possibly rely on one or more identity provider(s) and possibly even one or more identity provider(s) per tenant. For example, one tenant such as hearstmuseum.berkeley.edu could use CalNet as an identity provider, while another tenant such as brooklynmuseum.org might use an OpenID provider such as MyOpenID. Or hearstmuseum.berkeley.edu could accept identity assertions from both CalNet as well as an OpenID provider.

There could be two ways to choose an identity provider at the time of authentication.

1. Explicit: offer a list of identity providers to choose from at the login time. For example, see Plaxo's login screen. Plaxo recognizes principals authenticated by other identity providers such as Yahoo!, MyOpenID and Google.
   1. The list of identity providers could be pre-configured in a tenant-configured login page. For example, hearstmuseum.collectionspace.org (or collectionspace.org/hearstmuseum) could show a login page where the list shown is already approved by the tenant administrator on CollectionSpace for hearstmuseum.berkeley.edu (PHMA). The PHMA tenant administrator could determine this list at the time of the tenant registration process and also could modify it later.
   2. If there is only one identity provider in the list (e.g. CalNet), the list may not be presented to the user at all at the time of the login. Instead, that identity provider would be automatically used.
2. Implicit: Have a system defined algorithm relying on pre-configured list and order of the identity providers to query at the time of authentication. Note that, here, the selection of an identity provider could be part of the process of identifying a tenant.

It appears that explicit selection of the identity provider based on the pre-approved list by the tenant might be a cleaner and scalable approach.

Unknown macro: {multi-excerpt}

Issue: How to identify a tenant for a user associated with multiple tenants?

In cases, where a user might be associated with more than one tenants, it is important to identify which tenant's resources on CollectionSpace the user intends to use. In that case, the service would be looking for the service consumer to provide the identifier of the tenant as an HTTP session attribute called TENANT_ID at the time of login.

Unknown macro: {multi-excerpt}

We assume that the sign up process or how a new user is directed to sign up with an identity provider is not in scope for the authentication service. We believe that it is the application's responsibility to guide a new user through "sign up" or "account set up" process.

CollectionSpace would have a web application (or pages) to sign up a new user with default (out of the box) identity provider. This is described in more detail in [collectionspace:Account Service Description and Assumptions]

An application can use any of the following approaches to sign up a new user with a 3rd party identity provider :

1. Redirect the user to the identity provider tenant has chosen to use a single identity provider (e.g. Brooklyn Musueum might ask its users to sign up with Google ID)
2. Ask user to select an identity provider from a selected list (e.g. see Plaxo's sign in). User can go to any of the identity provider from the list and sign up there.
3. Ask user to independently sign up with a tenant-chosen identity provider. For example, Berkeley museums require CalNet ID to login to CollectionSpace. To establish a CalNet ID, one has to get "token" from a CalNet deputy who would verify the identity of the user in person.