User alias definition examples
User alias definition examples
The Push API allows you to define security identity relationships between a user security identity and other user identities defined across multiple security identity providers. These aliases indicate that all of the defined security identities correspond to the same person.
An alias definition must minimally contain:
-
The name of the security identity for which you want to create an alias in the security identity provider of your secured push source, as well as its entity type (normally
USER
). -
The name, entity type (normally
USER
), and security identity provider of each security identity with which to establish an alias relationship.
Notes
|
The alias definition may also contain the name and type (normally GROUP
or VIRTUAL_GROUP
) of each granted identity to assign to the alias (see MappedIdentityBody
).
Note
Granted identities used to be called well known groups.
To ensure backwards compatibility, the Push API still requires that you specify the granted identities of an alias in an array property whose name is |
Leading practice: Only define aliases between
USER entitiesAlthough you can establish alias relationships between any type of security identity, you should generally only define aliases between |
Defining a single alias for a user
Assuming that the target security identity provider only cascades to the Email Security Provider, this establishes an alias relationship between the user asmith
in the target security identity provider and the user asmith@example.com
in the Email Security Provider.
This also assigns the Everyone
granted identity to the alias.
{
"identity": {
"name": "asmith",
"type": "USER"
},
"mappings": [
{
"name": "asmith@example.com",
"type": "USER"
}
],
"wellKnowns": [
{
"name": "Everyone",
"type": "GROUP"
}
]
}
Defining many aliases for a user
This establishes an alias relationship between the user bjones@example.com
in the target security identity provider and the users bjones@example.com
and bjones1@example.com
in the Email Security Provider, as well as the user bob_jones
in mysecurityidentityprovider
.
This implies that the target security identity provider is properly configured to cascade to both of these security identity providers.
{
"identity": {
"name": "bjones@example.com",
"type": "USER"
},
"mappings": [
{
"name": "bjones@example.com",
"type": "USER",
"provider": "Email Security Provider"
},
{
"name": "bjones1@example.com",
"type": "USER",
"provider": "Email Security Provider"
},
{
"name": "bob_jones",
"type": "USER",
"provider": "mysecurityidentityprovider"
}
]
}