...
Use Cases by Characteristics
Use Case | Brief Desc | LoA Req | Local ID | Acct Link | AuthZ Process | Issues | General Risks/Concerns | 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 | Transient affiliates | AuthN used for privacy, but with no user history | None | No | No | External Implicit |
|
| Short term guests | AuthN for e.g., day visit access | |
"Open" Affiliates | Non-business affiliates accessing "public" services |
|
| No None | No | No | External |
| |||||||
Short term affiliate | AuthN for specific operation e.g., sign a form, edit document | Low | No | No | Pre-login (by invitee) |
|
| ||||||||
Wiki contributor | AuthN to a specific system | None | No | No | Implicit and Post-login |
|
| ||||||||
Parent | AuthN to see elements of student record (may be equiv to short term affiliate) | Low | No | No | Pre-login (by invitee) |
|
| ||||||||
External Researcher/Loose VO | AuthN to access multiple resources in institution (institution managed in one IdP) | High | Yes | Implicit | Managed via local IdM |
|
| ||||||||
Incoming Students/Prospects | AuthN for participation prior to enrollment | Initially Low | Eventually | One time (transition) | Initially implicit, later by local IdM |
|
| ||||||||
Alumni, separated employee (w/personal records access) | AuthN for participation in mailing lists | High | Yes | Yes | Self-asserted with local ID? |
|
| ||||||||
Cross enrollment | AuthN at multiple institutions, each institution maintains local ID | High | Yes | Yes | Based on local IdM characteristics |
|
| ||||||||
Bring Your Own Credential | Local account exists but for external account used for user authN | High | Yes | Yes | Self-asserted with local ID? |
|
| ||||||||
For Privilege Escalation | Local account has low security, external has high. Leverage high account to get priv escalation | High | Yes | Yes | ??? |
|
| As alternate factor, password recovery | AuthN allows reset of primary credential | High | Yes | Yes | Self-asserted with local ID |
| |
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?