User: A user is registered in any IDP. It typically has, for examply, a username and a password.
TB User: A user registered in the Trustbuilder Repository (TB IDP). A TB User always has a corresponding principal.
Principal: A principal is the combining entity of multiple subjects, where each subject is the identifying attribute of the user at one IDP. A Principal only has a corresponding TB User if the user has completed the enrollment and has set a password.
Subject: A subject is an “attribute” of a principle. Each IDP brings a different subject attribute to the principal. Although a subject attribute is not necessarily linked to only 1 IDP, this is a recommended situation.
The Auto-provisioning will create a new Principal if none exists in our database. Note that a Principal is created, and not a TB User. This means that the user will not be able to use the Trustbuilder Internal IDP to authenticate.
For this principal, only a User ID and the Subject attribute will be Auto-provisioned to the Trustbuilder internal IDP.
This is a deliberate choice, as the original IDP is still the master of the attribute values, and we do not want to be comparing and updating user attributes with each authentication by default. The "Provisioning Workflow" can still be used for more advanced provisioning use cases:
- Provision a user with additional attributes
- Provision a user in an external user repository
- Mapping a single subject attribute to multiple IDP's
The Auto-provisioning process will also link the Principal to the IDP which was used to authenticate. This happens for new & existing (but yet unlinked) Principals.<!--[if !supportAnnotations]-->
Subject Conflict with other IDP’s
- A subject attribute cannot be linked automatically while it is shared by different IDP’s, because this may introduce unintended consequences. We will log a configuration warning in this case.<!--[if !supportAnnotations]--><!--[endif]-->
- It’s not possible to create a user if any user attributes are marked as “required” because no value can be given.
- It should be considered not to use the “required” property from User Attributes, as there is no real practical use for it.<!--[if !supportAnnotations]--><!--[endif]--> The “required” property on SP or IDP attribute mapping should stay, however.
- If the user has no active session, a new principal is created, with just a User ID and this Subject Attribute.
- If the user has an active session, the subject attribute can be updated for this user.