Disparate Policy Store SSO requirements
Article ID: 261396
Updated On:
Products
Issue/Introduction
This is to provide a list of requirements to achieve Disparate Policy Store SSO.
Use case:
Company A has acquired Company B and both are using SiteMinder for SSO.
Without using SAML Federation or OpenID, goal is to achieve SSO using SMSESSION cookie.
Environment
Release : 12.8.x
Cause
Following are the obstacles to over come.
1. Company A cookie domain is aaa.com and Company B cookie domain is bbb.com so the cookies will not be submitted due to different cookie domains.
--> A cookie provider may be used to cover come this condition. Company B can update the ACO and have the CookieProvider set to aaa.com domain.
--> Or a Company B have their applications accessible by using aaa.com cookie domain.
2. SMSESSION cookie cannot be decrypted as Company A and Company B have different Agent Keys
--> Agent Keys must be synchronized so the SMSESSION cookie can be decrypted by the other side of agents.
--> smkeyexport -o{filename} -d{adminusername} -w{password} -c
3. SMSESSIONSPEC cannot be decrypted as the Session Ticket Key is different
--> Found in SMSESSION content
--> Importing Agent Keys will also include the Session Ticket Key. Agent Key export contains session ticket key and agent keys.
--> smkeyexport -i{filename} -d{adminusername} -w{password} -c
4. Session Ticket Key cannot be decrypted as the Policy Store Encryption Key (and Key Store Encryption Key if not using Policy Store Encryption Key) is different
--> Policy/Key Store encryption key must be matched. This may require exporting the data in clear-text, reset the key and import the data back to they will be encrypted using the new key.
--> Policy Store: XPSExport {exportfilename.xml} -xb -npass
--> Key Store: smkeyexport -o{filename} -d{adminusername} -w{password} -c
--> Reset Policy Store encryption key: smreg -init {newcleartextkey}
--> Policy Store: XPSImport {exportfilename.xml} -npass
--> This will overwrite existing policy store.
--> Key Store: smkeyexport -i{filename} -d{adminusername} -w{password} -c
--> ObjectID of the Agent Keys in this Keystore would be the same so they should get overwritten.
--> If this is being imported to other environment other than where it was exported, it is required to delete the Agent Keys prior to import to avoid getting 2 sets of Agent Keys.
--> Session Ticket Key would have same pre-defined ObjectID so it would get overwritten.
5. User Store Name is not found where this Session was initially authenticated against.
--> Found in SMSESSION content
--> Company B can create a user store with the same name used at Company A (and point it to the Company A's AD so the userDN would match)
6. UserDN is not found
--> Found in SMSESSION content
--> UserDN must also match so the user session can be validated and evaluated for authorization.
7. Unless using static Session Ticket Key and Agent keys, Company B Policy Servers keystore need to be kept in sync with Company A.
--> When Session Ticket Key or Agent Key is rolled, that Journal Entry gets stored in the Policy Store for other policy servers to get notified.
--> But due to disparate policy store, Company B policy servers will not be able to know the agent keys have rolled over at Company A keystore.
--> Company B Policy Servers then can point to the Company A Key Store but requires "EnableKeyUpdate=1" in their policy server registry to regularly check for updates in the keystore.
Resolution
As a result, following are the requirements for Disparate Policy Store SSO.
1. Policy Store Encryption Key(and Key Store encryption key if used)
2. Session Ticket Key (Use static key or Company B to point to Company A keystore and use EnableKeyUpdate=1 registry at the Policy Server)
3. Agent Keys (Use static key or Company B to point to Company A keystore and use EnableKeyUpdate=1 registry at the Policy Server)
4. User Store to be matched
1) User Directory with matching OID (takes precedence over User Store Name)
2) User store with matching name
5. UserDN
In case if there is a User Store at Company B that matches the ObjectID of the Company A's userstore, then that would be the best matching userstore even when there is another user store at Company B that has the exact same userstore name.
This can lead to the user session getting validated against the wrong user store and fail to get authorized at the Company B.
--> Delete and re-create the userstore at Company B that has same ObjectID as Company A. This would result in getting different ObjectID. (This usually happens when some objects are exported from Company A and imported into Company B policy store).
Feedback
