Use Cases by Characteristics
Use Case | Brief Desc | Services | Client Relationship | Real-World Person Map? | Local IDM Entry? | Attribute Link? | AuthZ/Registration | Issues/Risks |
---|---|---|---|---|---|---|---|---|
Anonymous | Providing access with no ongoing user tracking. E.g., based on ePSA or ePE only. |
|
| No | No | No | External |
|
"Open" Affiliates | Non-business affiliates accessing "public" services |
|
| No | No | No | External |
|
Non-business Affiliates | Individual with local permissions for "non-core business" purposes |
|
| Yes? | Entry, no account | Yes? | Business Invite |
|
Ad-hoc personal affiliates | Non-business affiliates gaining access to targeted local resources |
|
| No | No | No | Personal Invite | Should real-world person map be "yes?" We want to know who is accessing targeted local resources. |
Business affiliates | Business affiliates with affiliation |
|
| Yes? | Entry, no account | Yes | Business Invite | Does tracking the invitation initiator (local uid) make sense to this id use? |
Inbound affiliate | Someone granted temporary access based on external credentials, but expected to migrate to (potentially more-highly vetted) internal credentials at a later point |
|
| Yes | Yes (but not immediately) | Transitional | Business Invite |
|
Outbound affiliate | Someone with internal credentials, who is expected to lose access to those credentials (and replace them with an external credential) |
|
| Yes | Yes | Yes | Self Linking |
|
Alternate factor | Using an external ID to provide privilege escalation in certain contexts |
|
| Yes | Yes | ??? | Self Linking |
|
Legend
Description of terms in the above table
Term | Description | Notes on values |
---|---|---|
Use Case | Generic name of the category being described |
|
Brief Desc | Brief Description of Use Case |
|
Service | List of examples IT services to which this Use Case would provide access |
|
Client Relationship | Typical business customers; i.e., "who would use this service" |
|
Real-World Person Map? | Is it important to the local services to know or validate the identity of the person in control of the external credential (as opposed to just validating the credential)? |
|
Local IDM entry? | Would the local IDM system typically maintain an Identity record describing this individual? (May impact SP- vs IdP- centric solutions) | Yes implies an identity and credentials are locally managed. |
Attribute Link? | Would local IT services expect to leverage attributes from the user's local (IDM-managed) Identity as part of IAM interactions? (May impact SP- vs. IdP-centric solutions) | Yes and No should be self explanatory |
AuthZ/Registration | Describes the general mechanism used to authorize the external credential to be used for access in this use case | External = Local systems trust external IdP assertions |
Issues/Risks | Lists both technical impediments to implementing/supporting and the business risk questions ("why we might not be willing to trust these IDs") surrounding this use case. |
|
What type of APIs would we want to support?