Best Practices for Managing User Attributes
RapidIdentity Cloud provides a robust schema that allows for the management of user’s identities. The RapidIdentity Schema has been designed in order to allow for multiple attributes to be stored in order to make decisions about a user's access and entitlements.
Even though the design allows for multiple fields, the recommendation is to only store attributes that are needed to manage and maintain a user's identity and what they need access to. The concept of Least Privileged Access should be taken into consideration when deciding on which attributes to send to RapidIdentity.
Things to consider:
- What are the attributes used for?
- Do downstream provisioning applications need this information?
- Are the attributes being store for Authentication (AuthN) or Authorization (AuthZ)
- Do the attributes allow for relationships between two identities?
- Do they provide access to entitlements
- Can they be used in Roles Based Access Controls (RBAC) or Attribute Based Access Controls (ABAC)
Identity Automation can make recommendations as to what should be provided, and what is needed for a successful identity management implementation. We look at the transferring of data to be a partnership between the two parties in order to meet the successful needs of the implementation. Below you will find a table of requirements for RapidIdentity as well as suggestions for attributes that should be provided if they are available in your source of authority.
Schema Overview
The Current version of the RapidIdentity Schema can be found here: RapidIdentity Directory Schema
Even though LDAP is referenced, it is a LDAP implementation configured by Identity Automation that can be replaced at any time for more efficiency and functionality with no impact to the environment. All implementations and updates should include a RapidIdentity certified administrator.
Attributes
| RI Attribute | Friendly Name | Identity Need | Description |
|---|---|---|---|
| givenName | First Name | YES | First Name of a person. The purpose is to identify a user's identity with a person. |
| idautoPersonMiddleName | Middle Name | No | Middle Name of a User. If available this is highly suggested to differentiate between two individuals with the same first and last name |
| sn | Last Name | YES | Last Name of a person. The purpose is to identify a user’s identity with a Person |
| displayName | Display Name | YES | The Full Name of a user, consisting of all named attributes. |
| idautoPersonStuID | SIS ID | YES | The Student Information System Unique Identifier |
| idautoPersonHRID | HR ID | YES | The Human Resource System Unique Identifier |
| idautoPersonSourceStatus | Status | YES | Denotes Whether a person is Active or Inactive in a source system. This can be Active or Inactive, A or I, or other attributes that can be used to derive an active or inactive status. Examples are FTE = Active, Retired, Terminated, or Suspended = Inactive |
| NO | Typically derived by RapidIdentity. Can be provided by the system if they own the Email address generation. | ||
| mobile | Phone Number | NO | The Cell phone number of a user. This IS needed if providing Password Reset functionality via SMS. |
| idautoPersonHomeEmail | Personal E-Mail | NO | A personal email of the user, NEEDED if providing Password Reset Functionality via EMail. |
| manager | Manager | NO | The Manager of the user. Typically provided in the form of an ID, and derived to a user specific ID in RapidIdentity. This will allow for delegated access from the manager to the end user. |
| idautoPersonDeptCodes | Department Code | YES | Department of a staff user. Used for groupings, and ABAC |
| idautoPersonLocCodes | Location Code | YES | Location of a User. Used for groups and ABAC |
| idautoPersonJobCodes | Job Codes | YES | A Persons Job Code. Used for Groups and ABAC |
| idautoPersonSchoolCodes | School Codes | YES | Schools a person is associated with. This is MANDATORY when using Analytics within RapidIdentity |
| idautoPersonSchoolNames | School Names | YES | School Names a person is associated with. This is MANDATORY when using Analytics within RapidIdentity |
| idautoPersonJobTitle | Title | NO | TItle of a User. Useful in identifying a user outside of a code |
| idautoPersonGradeLevel | Grade | YES | Grade Levels associated with an identity. |
| idautoPersonEmployeeTypes | Roles | YES | The roles a user is associated with on a granular level. Example - Teacher, Admin, Para |
Derived Attributes
Derived Attibutes are created by the RapidIdentity system.
| RI Attribute | Friendly Name | Identity Need | Description |
|---|---|---|---|
| idautoID | idautoID | YES | Unique Identifier for RapidIdentity |
| idautoPersonSamAccountName | sAMAccountName | YES | The username of a user, that is synced to secondary systems, such as Active Directory. This follows Active Directories standards of 20 characters and unique per system. |
| idautoPersonUsernameMV | Usernames | YES | All Usernames that a user can login with to RapidIdentity. By Default provisioning takes into account mail, and idautoPersonSamAccountName. Unique ID’s CAN and are suggested to be included. If this is included you must make sure the ID is unique across various platforms. Example. HR System and SIS may have the same ID for two different users. This cannot be used in idautoPersonUsernameMV |
| YES | This is typically derived by the system and synced downstream. It is also referenced above depending on the deployment of the RapidIdentity Platform. | ||
| EmployeeType | Role | YES | Based on the source of Authority. MUST be Staff, Student, Sponsored or Parent |
These are all suggested attributes for a successful deployment of an Identity and Access Management System and are found in all standard HR and SIS platforms. Not including some of these attributes will limit what you can do with a platform and make it difficult to scale the platform moving forward. With that said, Attributes are easy to add to the system, but business rules and processes may need to be adjusted and retested within the system.
OneRoster Mappings
The attributes below are derived from the users endpoint.
| OneRoster | RapidIdentity |
|---|---|
| sourcedid | idautoPersonStuID |
| status | idautoPersonSourceStatus |
| givenName | givenName |
| familyName | sn |
| middleName | idautoPersonMiddleName |
| orgs -> sourcedId | idautoPersonSchoolCodes |
| orgs -> href -> name | idautoPersonSchoolNames |
| grades | idautoPersonGradeLevel |
| phone | idautoPersonHomePhone |
| username | idautoPersonSystem1ID |
| idautoPersonHomeEmail |