The idea of minimal person data in the registry is driven by requirement # 10 and the idea that the data repository for IAM
is comprised of a registry, a group and a ODS/MDM person data repository. Data for IAM operations can go to or be
brought from the virtual combination of these three data repositories.
This is a final DRAFT doc. Review is in-progress by TIER WORKGROUP
Diagram from May 2016 TIER Entity registry documents.
The three data classes defined include:
- Entity Registry - person and non-person objects that require access management functionality and interface to that functionality.
- Entity Groups and Privileges – TIER proposes through the Grouper Implementation Guide a useful strategy for defining groups
of securable entities from the systems of record “Basis Groups”, transformational abstractions into Reference Group forms then
relating these to form Application related permission groups. See the TIER Grouper Implementation Guide for more details. - ODS, master data, data hub - unified and normalized person or entity data concepts an institution elects to manage independent
of IAM and useful to many line of business applications.
Why propose a minimal/thin Registry?
- Avoid rebuilding an ODS or MDM structure that may already be in place or on the institutions strategic path. Use it as a component of the repository.
- Use of a common person (subject) data HUB that is available to application is becoming more prevalent. This can be leveraged by the IAM application as well.
- Agility and flexibility downstream.
- Reduce PII and other privacy implications in the registry.
- Isolate the access management info and the growing aspects federation from the more data rich environment of the data hub.
- IAM is a SOR for Access management info. So for same reason we have other vertical applications that use a common reference data the IAM
Registry can be thought of in the same manner. - Security - Access data only needs to be shared with those with a need to know. Exposure of data is less.
- Groups and Provisioning in an RBAC or ABAC model is better if driven from a Grouping /Provisioning tool (Grouper, Midpoint, etc)
Why not use a thick registry?
- Generally does not scale as well as thin designs
- Produces more data duplication and with other services (like ODS or data hub).
- Duplication of efforts and talent in your IT organization
- Efforts to build thick registries can create complexities and related operational problems.
- More risk based on projects undertaken in the past
This document focuses on TIER PERSON and TIER CLIENT entity can be extended to document other supported entity types.
Requirement Document located for TIER registry and other TIER components at Requirements on an Entity Registry and Related Components
Entity Object- person, institutional contact, code client (thing calling API), service/privileged acct, IOT(device), etc.
- Each occurrence will have a unique identifier assigned to identify it for use in the IAM architecture to uniquely know this “thing” from all other “things”.
- This requires a high level structure in the data to provide uniqueness for all entities.
- In the case of matching, merging of suspect records this is a key capability.
==========================================================================
Entity Data Definition:
used for all type of entities
- Entity object ID
- internal
- used internal to registry only
- UUID of value
- Key value for any registry entry
- Entity Type Code
- Date created
- Date Inactivated
- Entry Description / Name
- (suspect, merged, active, inactive)
- Inactive = soft delete
- Institutional Entity Identifier
- Object Maintenance Fields ( rather than show this at each object or field this is shown once and can be applied to any object and /or field))
i. Begin Time Stamp
ii. End Time Stamp
iii. Updating entity ID
iv. Updating Identifies SOR (or Business area) of last update
Entity Type: person
Person object:
Protect/Secured
Definition – Person entity is accessible or is protected from exposure, although a more robust solution for privacy could be extended to each/all lower level object or fields this is the minimal level. Person on/off.
Requirement(s) – Allowed are “Y” or “N”
Additional Information - Person information may not be public because of person preferences or for legal protection reasons.
There are persons with specific security roles that have access to Protect/Secured information.
Specific roles have maintain authority Protect/Secured.
Active, Inactive and Pending Status
- Identifier Object (At least one occurrence is required many are allowed per institutional need, "Institutional Entity Identifier" from the Entity object must reside in person identifier have used a bunch of examples (these can vary per institution)
- Identifier Type Code (bold types are minimal required)
- SOR owned
- Institutional Identifier
- Registry is the SOR
- only required identifier
- requirement 4 would return the institutional identifier value to the calling client / SOR
- “ANY SOR ID” - extend as needed for HR, SIS, BANNER or whatever, SOR level is recommended strongly for all SOR with a reference identifier.ORCID -- needs to be provided by the ORCID organization; there is a format that is required;
- ERA Commons ID -- no special editing; for National Institute of Health
- NSF -- no special editing; National Science Foundation
- ID Card NO – no special editing; card ID for a person
- Library ID -- no special editing; Library Number
- Door Badge ID-- no special editing; SOR is ID card interface
- Access management identifiers
- (USERIDs various net id local or federated, it would be expected that one of these would be present) )
- UserName -- no special editing; Highly recommended
- federated login identifier(s)
- eppn or similar federated id of choice.
- Name object (Structure Occurs at least once but may be multiple per Person entity (1-M) )
- Name Type
- Definition – Name of the person. Tier Minimal registry requires two specific types of names to be available for entry. One should always be contained in the person info. Both being present is even better.
- Legal - Name associated with gov't documents such as Driver's License, Passport etc. This implies info has been vetted for the person.
- Preferred Name - Name provided with little or no vetting and often desired by the user.
- other possible types Former, Alias, etc
- Institutional control in adding types
- Formatted Name
long string that contains the name parts all combined into a single string value
- First Name
- Requirement(s):
- Value is required
- Fail transaction if null
- Middle Name
- Last Name (Surname)
- Requirement(s):
- Value is required
- Fail transaction if
- Prefix
- Suffix
- Contact Method Email Object
- multiples allowed
- 1 required
- Primary
- Email Type
- Email Address
- Contact Method Telephone Object
- multiple allowed
- 0 required
- Basic Phone International apply
- Primary
- Type – Maintain the type of device (example types are Wired and Cell)
- Telephone Number – Full number is to be stored
- Country Code
- Area Code
- Telephone Number
- Device Type
- SMS Capable
Entity Type: application (represent a thing that calls a TIER API)
- Identifier ID
- Institutional Id – required for all client objects
- Contacts 1-m (who can be notified for any actions about this client)
- Identifier - EPPN
- Name - friendly name
- Email -
- Sponsor
- identifier: a permanent (friendly) unique identifier
- name: friendly name
- sponsor: Id of the sponsor of this sponsor. ( Null iff the root sponsor )
- Service
- identifier: a permanent (friendly) unique identifier
- name: friendly name
- description: Human readable description of this service.
- sponsor: Id of the Sponsor of this service.
- admins: list of administrators ( eppns usually )
- contacts: list of Contacts
- base URL: host, port, base path
- authns: list of authentication methods supported
- authorization service: Service of OAuth authorization service ( if OAuth supported )
- Client
- identifier: a permanent (friendly) unique identifier
- name: friendly name
- description: Human readable description of this client.
- sponsor: Id of the Sponsor of this client.
- admins: list of administrators ( ePPNs usually )
- contacts: list of Contacts
- redirect urls: list of redirect_url ( if OAuth supported )
- host: if known and constant.
- long-term authentication credential
- to itself for each client in its registry.
- A service will generally authenticate to the CSR with its InCommon certificate.
Audit trail : or similar mechanism is required to be able to review and look at all changes to data.
- entity, attribute identifier, verb, old value, new value, timestamp of change (example)
- should be able to trigger an update notifications/events to Provision when an “attribute” changes on a Person record
- this can vary based on the specific implementation of this design
_________________________________________________________________
Additional info for Virtual Organization consideration:
Notes on support for VOs and collaborations wrt Minimal Entity Registry Data
Requirement #57
Support for collaborations (as provided by central IT) can broadly be segmented into two categories;
"Simple" collaboration needs cover researchers on campus (ie: those who have campus NetIDs) collaborating with others on campus via access to campus managed services (email lists, documentation spaces, etc). In general, this functionality can be provided with a combination of (existing) group and person registry services, often with a minimal "service enablement" layer to allow authorized individuals to define the collaboration groups and map them into enabled services.
"Advanced" collaboration needs expand to include researchers not affiliated with the campus (ie: those who would leverage federated identity to participate), complex enrollment procedures (invitation, self signup, approval, etc), larger collaborations with delegation requirements, and finer grained service management. Meeting these needs often implies solutions like COmanage.