SQL Claim Transformation
This transformation rule gives a lot of flexibility but should be used with care. The rule is especially smart when you need to save values from the token into external databases; it can also be used for updating the Safewhere Identify database. A typical example is if you extract information of a new organization from an incoming user's token and want to have this organization created, then this type of rule is perfect. It could also be used to create new users, if you want them specified in a certain way that does not fit with the existing user creation system in Safewhere Identify. Another typical situation is when you want to save information from the token to the user because Safewhere Identify does not allow you to do this.
The Transformation consists of five sections:
Claim Transformation Name: Give the Transformation object a name that will make it easy to recognize when adding to the Pipelines of Authentication and Protocol connections.
Culture: Since expression may be using and comparing numbers, it is important for the system to know what culture is used in order to know whether comma or dot indicates a decimal point. Currently only two cultures are supported, Danish (comma is decimal point) and American (dot is decimal point). These should cover the needs of other cultures in regards to this issue.
Owner Organization: The organization that the Claim Transformation is added to.
Execute before loading claims from local store: By default, a claim transformation rule is executed after claims from local store are loaded for a principal. Check this option to let it execute before the load.
Conditions: It is possible to specify that the Transformation object is only applied to a Pipeline given certain conditions of the token or user is in place, include:
- The option to skip the Transformation step when the token belongs or does not belong to a user identified as existing in the Safewhere Identify repository.
- The option to specify that the Transformation object is not applied when token is processed via specific Authentication Connection or Protocol Connection.
- The option to specify regular expressions that define which tokens are to be exposed to the transformation step. Please see the Using Regular Expressions in Claim Transformation Conditions section to learn more.
SQL Server: Specify the connection string for the database that you want to interact with and then define the SQL script that must be run against the database.
- Connection String: The connection string that will give you access to the used database.
- Re-cache Main Data: If the SQL script regards changing organization data in the Safewhere Identify database, then a recaching of main data will be necessary. When necessary, enable this check box.
- Re-cache User Data: The check box used when updating user data in Safewhere Identify with the script.
- SQL Script: The script that will be used for the database specified in the connection string. You can insert claim type names as in the following example, and the claim type will be replaced with the value extracted from the claim type of the user's token at runtime. For example:
Update [abc].[UserValue]
Set Email=N'{{http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress}}'
Where username=N'{{http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name}}'