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?