Organize user communities

First, it is critical to decide if and how to use realms when planning the object model.

You can organize distinct user communities, such as business partners and consumers in Identity Cloud. For example, you can distinguish users by implementing a shared property, such as a user type, or divide users by organizational membership.

The most complete separation of users is through the use of realms, which allows each community to have its own user properties, authentication and authorization policies, and journeys.

You can also separate users within realms through:

Organizations: Use organizations to separate identities with parent and children organizations.
Groups: Use groups to follow an organization structure or base groups on the needs and privileges of an arbitrary set of users.

User profiles

Another critical stage in data object modeling is deciding which properties to assign to users. This assignment is driven by your business application requirements. For example, you can assign properties to users based on the type and level of authentication required, and the level of access granted by passing authorization information to each application.

Storing user properties in Identity Cloud

When considering which user properties to store in Identity Cloud, there are a number of important considerations for each property that fall under the following points

Relevance
Data validation
Least privilege
Search enablement

Relevance: You should only store user attributes in Identity Cloud if they are used for identity management, authentication, or authorization. For example, if a user’s home address is never used during authentication and is never included in an ID or access token, then there is no requirement for this information to be stored in Identity Cloud.

Defining properties not in use in Identity Cloud creates unnecessary overhead and can introduce potential privacy issues. Once the data object model is live, you can always add properties to the model, but it is much harder to remove properties that can affect existing users.

Likewise, if the backend application fetches fine-grained user entitlements from an internal repository at access time, there is no need to include such entitlements in an access token; the token simply provides broad scope information to inform the application what constraints to apply for this method of access.

Also, when using OAuth2 access tokens, for example, the token can include a scope to indicate the broad permissions granted to the user; however, there is a balance between what authorization data Identity Cloud can deliver versus what additional entitlement checks can perform by the relying applications themselves. For example, the scopes and privileges included in an access token versus the resource access privileges held within an internal entitlements repository for the subject of that token. The commonality of authorization requirements between business applications also influences what authorization data can deliver.
Data validation: Each property should have a validation policy applied to it to maintain the integrity of the identity data. It is important to establish validation policies in full ahead of going live in production. Adjusting validation policies to live production data is complicated. Any policies applied retroactively to existing identity information cause issues when updating existing identities.
Least privilege: For each property defined in the data object model, you should apply the principle of least privilege. For properties that the user should not be able to update directly, the user editable setting should be disabled. For properties that should only be accessed internally, you should disable any viewable option, such as a managed object event trigger or custom endpoint. For more information on setting this property, refer to Creating and modifying managed objects.
Search enablement: If a property is used to search for identities, such as retrieving a list of users by their surname or finding users who have not logged in for over a year, then the property must be a searchable field. Identity Cloud implements this as an indexed field. For more information on rhe searchable field, refer to Creating and modifying managed objects.

The property can either be a standard search field, such as sn, or an indexed placeholder field, such as frIndexedString1. Custom fields added by the customer, for example custom_userType, cannot be searched upon. Since there are a limited number of searchable user fields, you must use care when using indexed placeholders for fields that will never be searched on.