Federated Strong Employee ID

From IDESG Wiki
Revision as of 23:13, 20 May 2020 by Tomjones (talk | contribs) (→‎References and Citations)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Title: Federated Strong Employee ID authenticated to external sites sanctioned by the Employer

Use Case Description: Use existing strongly authenticated employee identity certificate to create claims that are accepted by employer approved web sites, either internal or external to the employer's enterprise. While this use case focuses on the employee-employer relationship, it would work equally well for any case where their is a contractual relationship between the user and the identity provider (IdP).


Use Case Category: Authentication, Federated Identity
Contributor: Tom Jones

Use Case Details

Actors:

  • User (aka employee) in this case is an entity authenticated by an enterprise employer that is willing to create a claim to a specific site. Note that not only employees but other entities, like groups of individuals or contractors can have enterprise credentials.
  • User agent in this case is an entity that controls inclusion of the user's private attributes in the bucket of claims provided to the RP.
  • Identity Provider in this case is an enterprise that can strongly identify entities and that has some contractual authority to control the user's behavior when authenticated using the employer provided credentials.
  • Relying party (RP) in this case is a specific internet connection web site, not always part of the enterprise.


Goals: The goal is to provide an identity from an enterprise to a federated site (the RP) with all information needed by the RP to make the authorization decision.

Assumptions:

  • The enterprise will have some contractual or ownership role with the user. These contractual obligations made by the user are often important to the relying party.
  • Typically the claim created by the enterprise will contain the enterprise internal identifier for the user. Note that some enterprises create alias that are not specific to any individual or that obfuscate that individual's real world identity for reasons that it need not disclose to the relying party.
  • The user agent will be assumed under the control of the enterprise employer for this use case. Typically the claim provided to the relying party will contain attributes that are unique to the user and the enterprise will be operating under some regulatory compliance constraints that control the release of user private data to the RP.
  • Proof of strong authentication of the user will be an attribute provided by the employer's IdP.


Requirements:


Process Flow:


Success Scenario:


Error Conditions:


Relationships

  • Extended by:
  • Extension of:

References and Citations