Role Engine / Common Identity Use Cases
From Bandit-project.org
Contents |
CASA
Introduction
The server side of Common Authentication Services Adapter (CASA) needs configurable access to various identity repositories in order to validate credentials and build secure tokens and certificates for the client. The credentials may be partial, requiring contextless login, it is possible that more than one repository/authentication method may need to be attempted, and it is assumed that attribute names and other identity information may not be the same in every repository.
By building on the Common Identity repository independence may be achieved.
Actors
Pre-conditions (assumptions)
- It is assumed that the Common Identity has been properly configured
- Credential information has been passed from the client
Post-conditions
- Credential information has been matched with an identity and either authenticated or rejected
Basic Flow
- Server Side CASA receives credentials and hints from a client
- Using the hints CASA selects a realm to search for the identity, this may be a join realm, and performs a search
- For each realm selected the Common Identity:
- Takes the base name and checks to see if there is name location configured, name location is policy based and may take the original search and make many searches into different contexts within the information repository
- If a suitable object is found then the attributes CASA requested are read/converted/generated and returned to CASA
- For each realm selected the Common Identity:
- User is found, CASA may then proceeded with the authentication steps
- CASA calls the Common Identity
Middle Tier Application
Introduction
This use case focuses on a web services middle tier application which needs to authenticate carbon-based and silicon-based identities, find policies which have been associated with the identity either explicitly or via some kind of identity aggregation, and needs to administer it's own data as it relates to the identity associations.
This middle tier application has goals to be independent from identity repositories, and specific web services platforms. The application will manage and authorize it's own application specific data and policies from an internal data store, however those policies and authorizations will have associations with local and non local identities.
Actors
- Identity Repositories
- Client side of Application
- Server side of Application
- Common Identity
- Role Engine
- Common Authentication Services Adapter (CASA)
Pre-conditions (assumptions)
- Middle tier fully configured, including
- Client authenticated (think Common Authentication Services Adapter (CASA) on top of the Common Identity)
- It is the responsibility of the the middle tier to interact with the various identity stores and get a digital subject.
Use Cases
Following are three middle tier application use cases:
- Middle Tier Application - Assigned Roles
- Middle Tier Application - Authorization
- Middle Tier Application - Association Management
Middle Tier Application - Assigned Roles
Introduction
Middle Tier Application Introduction
The middle tier application wants to be able to access assigned role information for identities that act in their system.
Actors
Middle Tier Application Actors
Pre-conditions (assumptions)
Middle Tier Application Pre-conditions
Post-conditions
Middle Tier receives lists of assigned roles
Basic Flow
- The Application calls the Role Engine.
- The Role Engine calls the Common Identity and requests the information required to build a role list, which is then returned.
- Using the Role identifiers returned, the application may now lookup it's application policies associated with those roles in it's internal store.
Middle Tier Application - Authorization
Introduction
Middle Tier Application Introduction
The middle tier application wants to be able to authorize operations requested by identities that act in their system.
Actors
- Bandit XACML PEP
- Middle Tier Application Actors
Pre-conditions (assumptions)
Middle Tier Application Pre-conditions
Post-conditions
Middle Tier Application has it's operations authorized
Basic Flow
- The middle tier passes the identify artifact it holds to the XACML PEP.
- The XACML PEP calls the Role Engine which uses the Common Identity and configured policy (which also happens to be specified as XACML statements)
- Using the role information returned from the Role Engine, the XACML PEP returns an "allow" or "deny" for the specified operation.
- The following diagram shows how the bandit components would be leveraged:
Middle Tier Application - Association Management
Introduction
Middle Tier Application Introduction
The middle tier application wants to be able to manage associations between entries in it's application specific data store and identities in a variety of identity stores.
Actors
Middle Tier Application Actors
Pre-conditions (assumptions)
Middle Tier Application Pre-conditions
Post-conditions
Middle Tier manages identity associations
Basic Flow
- Using UUIDs from identity information accessed through the Common Identity, the application may keep associations in it's data store.
- UUIDs may be turned in to readable names through calls to the Common Identity.
