Information Technology Reference
In-Depth Information
Needless to say, if there is even one system that has to generate its own
Local User IDs, IAM would have to be configured to listen on User Event
Acknowledgement messages. As always, messages are assumed to be
persistent and IAM's subscription to these messages is assumed to be
durable, so no messages will be lost even in the event of a bus crash or IAM
being temporarily offline.
2. Fallback Model (when the User UUID is not universally supported):
If the User UUID cannot be relied upon to be a candidate key across systems,
then the user provisioning data design expectedly becomes less elegant and
more complex. The Local User ID now has to be relied on as the only
identifying “key” on systems that do not support the User UUID.
We find that instead of sending out a single, standard representation of
current user state, we will need to send four different messages based on
the nature of the user event. These are:
1.
Create User
2.
Delete User
3.
Update User Attributes
4.
Change Local User ID
The “Create User” message would look like this:
Fig 53: Create User message
