Attribute Fields - Best Practices
  • 26 Jun 2023
  • 4 Minutes to read
  • Dark

Attribute Fields - Best Practices

  • Dark

Article summary

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

Important to Note:

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.


RI AttributeFriendly NameIdentity NeedDescription
givenNameFirst NameYESFirst Name of a person. The purpose is to identify a user's identity with a person.
idautoPersonMiddleNameMiddle NameNoMiddle Name of a User. If available this is highly suggested to differentiate between two individuals with the same first and last name
snLast NameYESLast Name of a person. The purpose is to identify a user’s identity with a Person
displayNameDisplay NameYESThe Full Name of a user, consisting of all named attributes.
idautoPersonStuIDSIS IDYESThe Student Information System Unique Identifier
idautoPersonHRIDHR IDYESThe Human Resource System Unique Identifier
idautoPersonSourceStatusStatusYESDenotes 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
mailE-MailNOTypically derived by RapidIdentity. Can be provided by the system if they own the Email address generation.
mobilePhone NumberNOThe Cell phone number of a user. This IS needed if providing Password Reset functionality via SMS.
idautoPersonHomeEmailPersonal E-MailNOA personal email of the user, NEEDED if providing Password Reset Functionality via EMail.
managerManagerNOThe 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.
idautoPersonDeptCodesDepartment CodeYESDepartment of a staff user. Used for groupings, and ABAC
idautoPersonLocCodesLocation CodeYESLocation of a User. Used for groups and ABAC
idautoPersonJobCodesJob CodesYESA Persons Job Code. Used for Groups and ABAC
idautoPersonSchoolCodesSchool CodesYESSchools a person is associated with. This is MANDATORY when using Analytics within RapidIdentity
idautoPersonSchoolNamesSchool NamesYESSchool Names a person is associated with. This is MANDATORY when using Analytics within RapidIdentity
idautoPersonJobTitleTitleNOTItle of a User. Useful in identifying a user outside of a code
idautoPersonGradeLevelGradeYESGrade Levels associated with an identity.
idautoPersonEmployeeTypesRolesYESThe 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 AttributeFriendly NameIdentity NeedDescription
idautoIDidautoIDYESUnique Identifier for RapidIdentity
idautoPersonSamAccountNamesAMAccountNameYESThe 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.
idautoPersonUsernameMVUsernamesYESAll 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
mailMailYESThis is typically derived by the system and synced downstream. It is also referenced above depending on the deployment of the RapidIdentity Platform.
EmployeeTypeRoleYESBased 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.

orgs -> sourcedIdidautoPersonSchoolCodes
orgs -> href -> nameidautoPersonSchoolNames

Was this article helpful?