To work properly, a-Order needs a number of claims to be supplied:
- User name
The "Organization” claim is used to filter orders belonging to a specific customer of Adatum. For example, Litware users (like Rick) will eventually end up with a token containing a claim with “Organization=Litware”. All this is done in step 3 here in the diagram below:
Adatum’s FP takes whatever token it gets from the outside world and “normalizes” it to whatever the application needs. ADFS for example, ships with a powerful language to define these transformations. In our sample, we ship a simple “simulation” of a real STS, so our rules are all coded in C# and are obviously not “production”:
With ACS in the picture there are 2 places where transformation could happen though:
- In ACS
- In Adatum’s FP
In this scenario Adatum owns both (its own on-premises issuers and an instance in ACS), so it has full control of either components. Which one to use depends on many factors and there’s no “single right” way of doing it. Let’s consider one reason to keep mappings on Adatum’s side. for this we’ll pick one of the transformations required: the simple rule of associating “Mary@Gmail.com” with Organization=“Mary Inc”.
This rule would be fixed in ACS, there is no dynamic discovery or lookup code that ACS can execute at this time. It is likely that Adatum keeps a master record of all the companies it works with and the contact information associated with them. If that is the case, it’s probably better to have ADFS call a component or the master record database using the built-in SQL integration capabilities (if using ADFS). If Mary changes her e-mail, everything would just work. If the rule was in ACS, it would require Adatum to update the rule every time there’s an update.
Of course, ACS does provide an API for updating the configuration. So you could achieve something similar by just automating the update. Different companies will be more or less comfortable with one approach or the other.