I am back with a blog that was inspired from a question posted on the OTN forums, the poster asked if it was possible to use single sign in EAS to connect to two Essbase servers which are managed by separate Shared Services instances.
The initial answer is no because each Shared Services instance will use a unique CSS token encryption key but the answer changes to yes it is possible with the help of a utility.
Before I go through the process on how to achieve the single sign-on between environments I want to stress that this is just an example which may not be supported and it is not something I endorse so think about the consequences and security aspects before attempting.
I will be using 11.1.2.3 in the example but it should also be valid on 11.1.2.2
Both environments have been configured to use the same external directory in Shared Services as I don’t believe it will work with native directory accounts.
An AD user called essbaseadmin has been provisioned with the Essbase administrator role on both environments.
I have already added the first Essbase server using SSO in EAS and as this it is using the same Shared Services instance there are no problems connecting to it.
Now let’s add an additional Essbase server which is managed by a separate Shared Services instance.
The “Use Single Sign On” option was selected.
Connecting to the Essbase server fails with the standard login fails due to invalid login credentials error.
Usually you would just add the server without using single sign-on and enter the username and password to connect with, I don’t see the problem with this and it should be the way to connect but that is just my opinion.
Anyway back to the original question and how to achieve the single sign-on, if you take a look on a foundation server in the directory:
<MIDDLEWARE_HOME>\EPMSystem11R11\common\CSS\11.1.2.0
you will see a zipped up file called regSyncUtil_EPM-to-EPM.zip
The archive file contains a pretty unknown utility which allows the migration of the CSS token encryption key between two Shared Services registries so a CSS token generated on the source environment should validate on the destination environment.
If you have ever gone through the process of single sign-on integration between Workspace and OBIEE then you will have used the same utility to migrate the encryption key.
Before running the utility there are a couple of steps that need to be completed.
If running the utility is successful the key should be read from the source registry and imported into the destination registry.
If you compare a registry report before and after running the utility you will see the CSSHandlerKey2 property value is updated.
Now that is done the Essbase server can be added again in EAS.
Once again the “Use Single Sign On” option is selected.
And there we go the user is able to log straight into the Essbase server using SSO.
This concept can no doubt be used for other products that generate and pass a SSO token.
The initial answer is no because each Shared Services instance will use a unique CSS token encryption key but the answer changes to yes it is possible with the help of a utility.
Before I go through the process on how to achieve the single sign-on between environments I want to stress that this is just an example which may not be supported and it is not something I endorse so think about the consequences and security aspects before attempting.
I will be using 11.1.2.3 in the example but it should also be valid on 11.1.2.2
Both environments have been configured to use the same external directory in Shared Services as I don’t believe it will work with native directory accounts.
An AD user called essbaseadmin has been provisioned with the Essbase administrator role on both environments.
I have already added the first Essbase server using SSO in EAS and as this it is using the same Shared Services instance there are no problems connecting to it.
Now let’s add an additional Essbase server which is managed by a separate Shared Services instance.
The “Use Single Sign On” option was selected.
Connecting to the Essbase server fails with the standard login fails due to invalid login credentials error.
Usually you would just add the server without using single sign-on and enter the username and password to connect with, I don’t see the problem with this and it should be the way to connect but that is just my opinion.
Anyway back to the original question and how to achieve the single sign-on, if you take a look on a foundation server in the directory:
<MIDDLEWARE_HOME>\EPMSystem11R11\common\CSS\11.1.2.0
you will see a zipped up file called regSyncUtil_EPM-to-EPM.zip
The archive file contains a pretty unknown utility which allows the migration of the CSS token encryption key between two Shared Services registries so a CSS token generated on the source environment should validate on the destination environment.
If you have ever gone through the process of single sign-on integration between Workspace and OBIEE then you will have used the same utility to migrate the encryption key.
Before running the utility there are a couple of steps that need to be completed.
- Copy reg.properties from the source environment to the src folder.
- Edit runRegSyncUtil.bat and update the ORACLE_HOME,ORACLE_HOME,JAVA_HOME variables to contain the correct full paths
If running the utility is successful the key should be read from the source registry and imported into the destination registry.
If you compare a registry report before and after running the utility you will see the CSSHandlerKey2 property value is updated.
Now that is done the Essbase server can be added again in EAS.
Once again the “Use Single Sign On” option is selected.
And there we go the user is able to log straight into the Essbase server using SSO.
This concept can no doubt be used for other products that generate and pass a SSO token.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.