Attribute Fields - Best Practices

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.

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
mail	E-Mail	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

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

Middle Name of a User. If available this is highly suggested to differentiate between two individuals with the same first and last name

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

mail

E-Mail

Typically derived by RapidIdentity. Can be provided by the system if they own the Email address generation.

mobile

Phone Number

The Cell phone number of a user. This IS needed if providing Password Reset functionality via SMS.

idautoPersonHomeEmail

Personal E-Mail

A personal email of the user, NEEDED if providing Password Reset Functionality via EMail.

manager

Manager

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

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
mail	Mail	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

RI Attribute

Friendly Name

Identity Need

Description

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

mail

Mail

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

Notes

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
email	idautoPersonHomeEmail

OneRoster

RapidIdentity

sourcedid

idautoPersonStuID

status

idautoPersonSourceStatus

givenName

familyName

middleName

idautoPersonMiddleName

orgs -> sourcedId

idautoPersonSchoolCodes

orgs -> href -> name

idautoPersonSchoolNames

grades

idautoPersonGradeLevel

phone

idautoPersonHomePhone

username

idautoPersonSystem1ID

idautoPersonHomeEmail

Attribute Fields - Best Practices

Best Practices for Managing User Attributes

Things to consider:

Schema Overview

Attributes

Derived Attributes

OneRoster Mappings

What's Next

Contact

Follow Us

Attribute Fields - Best Practices

Best Practices for Managing User Attributes

Things to consider:

Schema Overview

Attributes

Derived Attributes

OneRoster Mappings

Related articles

What's Next