Information Technology Reference
In-Depth Information
There are only three top-level elements of this message - the User UUID, a
composite “User Attributes” element comprised of individual elements (e.g.,
first name, last name), and an optional repeating element called “Associated
System”, which contains the ID of each associated system where that user's
data is to be held, along with the local User ID of the user within that system.
The semantics of such a message are simple.
If an associated system is referenced in the message through its ID, then the
requirement is for that system to “create or update” the user and to record
whichever user attributes are required by that system. This message can
even be used to modify the Local User ID on a system.
If an associated system is not referenced anywhere in the message, then the
requirement is for that system to “delete or ignore” the user. If the user is
currently held in the system, the record is to be deleted (or marked deleted).
If the user is not currently held in the system, the message is to be ignored.
The idempotence property ensures that repeated receipt of a message by a
system will have no additional effect after the first one.
This is therefore the simplest user provisioning model, and the one we
recommend.
The only complication here is with systems that need to generate their own
Local User ID and cannot accept one supplied by IAM. In such cases, IAM
would simply leave the Local User ID field blank. The associated system will
generate this ID, then send back a User Event Acknowledgement message
with the mapping of this ID to the User UUID, so that IAM can update its
“User-Associated System” table.
The User Event Acknowledgement message may look like this:
Fig 52: User event ack
