Update: Apologies, the ZIP file was altered by anti-virus software and this is not usable. I will have to update the script after I have come back from my travelling.
Update 2: The fixed ZIP file is now available! I will soon be starting a parallel project to create a very similar script in a proper programming language like Perl, Python, Java, Jython or possibly AutoIt. I believe Perl and Jython are supported out-of-the-box by EPM and OBIEE installations so they may be preferable - although I will have to double-check.
You will have to forgive the lack of posts recently, I have embarked on an adventure and don't always have ready access to a computer!
This is to release the next version of PDS (Patch Delivery System).
This set of Windows batch scripts provide a way of streamlining the process of patching a Hyperion EPM installation. Basically with a little preparation it means you can run one script that will install the patches in the order you require, giving the operator time to read the README file for each patch before continuing to the installation. This removes some of the manual effort from patching the system.
New features for this version include OBIEE support! This is assuming that the BI_ORACLE_HOME variable has been set, and the ORACLE_INSTANCE variable should also be set up. As an aside it is highly recommended to add these 2 environment variables to OBIEE installations whether you are using PDS or not as they resolve some issues.
Also there is some more error-checking and more prompts available to check with the operator if a patch has actually applied successfully or not.
For the next versions I would like to find a reliable way of detecting if a patch has applied successfully or not to remove the need to prompt the user for information - but that would require getting deep into the inner workings of OPatch, unfortunately.
You can download v0.2 of PDS here.
Monday 9 December 2013
Monday 21 October 2013
SAML2 SSO for EPM
So the last post was completely devoid of any kind of context as I was really writing it in a rush.
Here I will try to give some more details.
I have been spending some time configuring SAML2 SSO for EPM. SAML2 SSO is basically "seamless" single sign on - "one click and you are logged in". No need to type usernames and passwords.
The first thing you should know is that Oracle's documentation on the subject is sometimes confusing and sometimes wrong. That said the documentation is available here, and you should refer to it for the steps in detail. I will try to be as clear as I can when you need to differ from the documentation.
First of all you should patch your environment to the highest possible. If you are on 11.1.2.1 you need to download this patch to solve a bug with Workspace not logging in correctly with SSO:
17370092
Also you should know that as soon as you configure SSO, Planning will not start. This is due to a bug in Planning. The fix is in the Windows registry, you need to look for the startup parameters for Planning (under HKLM\Software\Hyperion Solutions\HyS9Planning, usually) and delete these parameters if they exist:
-Djavax.xml.parsers.DocumentBuilderFactory
-Djavax.xml.transform.TransformerFactory
In the example above those options have been overwritten with "-Djaxp.debug=0" - which does nothing.
If you do not Planning will crash as soon as SSO is set in the WebLogic domain.
Now a caveat: EAS Console, Essbase Client, Smart View, Essbase Excel Add-In, FDM Workbench, HFM Client and any of the other "thick" software clients do not support single sign-on of any kind. You will still get a login box.
Seamless SSO for Smart View may be coming in a later release, we will have to see on that one.
Firstly you should try to fully configure the authentication source in WebLogic and Shared Services. These will typically be an LDAP directory, they should both be configured in the same way and (under normal circumstances) use the same authentication source as the Federation Services server.
It is required in WebLogic as the actual SAML2 SSO is done as a WebLogic operation and as such when WebLogic takes the SAML2 response and tries to map the response to a user it will do so in the internal authentication providers of the WebLogic domain. Then it will pass the user to Foundation Services and it will get logged in automatically.
With the authentication providers set up you need to configure the Identity Provider Partner. There are guides on how to do that elsewhere so I won't cover it here.
The Service Provider configuration can be a little tricky, not least because Oracle doesn't tell you the correct URL to use as the for the Published Site URL. It should be http://server1:19000/saml2/ not
http://server1/.
The SSO configuration in Shared Services is quite straightforward, those steps are available in the guide.
The SSO Diagnostic application can be handy for diagnosing issues and should be deployed. The OHS configuration is required and should definitely be completed.
With the CustomRolesAndPolicies step - I think this might only be required if you wish to restrict SSO to only certain users. Even though this was not the case for my configuration I did it regardless.
If all these steps have been done then you should be up and running.
One issue we had is that by default WebLogic maps the Subject of the SAML2 response to the WebLogic user. If the user exists in WebLogic then the username is passed back to Foundaton Services to be logged on. This will probably be a required configuration 75% of the time but we wanted to map a specific attribute in the SAML2 response to a WebLogic user. Unfortunately the only way to do this is by writing a couple of custom Java classes to override the default way WebLogic maps SAML2 responses to WebLogic users. That is what the previous post covered.
I may go over the above steps in more detail some other time. Otherwise good luck on getting SSO in EPM :)
Here I will try to give some more details.
I have been spending some time configuring SAML2 SSO for EPM. SAML2 SSO is basically "seamless" single sign on - "one click and you are logged in". No need to type usernames and passwords.
The first thing you should know is that Oracle's documentation on the subject is sometimes confusing and sometimes wrong. That said the documentation is available here, and you should refer to it for the steps in detail. I will try to be as clear as I can when you need to differ from the documentation.
First of all you should patch your environment to the highest possible. If you are on 11.1.2.1 you need to download this patch to solve a bug with Workspace not logging in correctly with SSO:
17370092
Also you should know that as soon as you configure SSO, Planning will not start. This is due to a bug in Planning. The fix is in the Windows registry, you need to look for the startup parameters for Planning (under HKLM\Software\Hyperion Solutions\HyS9Planning, usually) and delete these parameters if they exist:
-Djavax.xml.parsers.DocumentBuilderFactory
-Djavax.xml.transform.TransformerFactory
In the example above those options have been overwritten with "-Djaxp.debug=0" - which does nothing.
If you do not Planning will crash as soon as SSO is set in the WebLogic domain.
Now a caveat: EAS Console, Essbase Client, Smart View, Essbase Excel Add-In, FDM Workbench, HFM Client and any of the other "thick" software clients do not support single sign-on of any kind. You will still get a login box.
Seamless SSO for Smart View may be coming in a later release, we will have to see on that one.
Firstly you should try to fully configure the authentication source in WebLogic and Shared Services. These will typically be an LDAP directory, they should both be configured in the same way and (under normal circumstances) use the same authentication source as the Federation Services server.
It is required in WebLogic as the actual SAML2 SSO is done as a WebLogic operation and as such when WebLogic takes the SAML2 response and tries to map the response to a user it will do so in the internal authentication providers of the WebLogic domain. Then it will pass the user to Foundation Services and it will get logged in automatically.
With the authentication providers set up you need to configure the Identity Provider Partner. There are guides on how to do that elsewhere so I won't cover it here.
The Service Provider configuration can be a little tricky, not least because Oracle doesn't tell you the correct URL to use as the for the Published Site URL. It should be http://server1:19000/saml2/ not
http://server1/.
The SSO configuration in Shared Services is quite straightforward, those steps are available in the guide.
The SSO Diagnostic application can be handy for diagnosing issues and should be deployed. The OHS configuration is required and should definitely be completed.
With the CustomRolesAndPolicies step - I think this might only be required if you wish to restrict SSO to only certain users. Even though this was not the case for my configuration I did it regardless.
If all these steps have been done then you should be up and running.
One issue we had is that by default WebLogic maps the Subject of the SAML2 response to the WebLogic user. If the user exists in WebLogic then the username is passed back to Foundaton Services to be logged on. This will probably be a required configuration 75% of the time but we wanted to map a specific attribute in the SAML2 response to a WebLogic user. Unfortunately the only way to do this is by writing a couple of custom Java classes to override the default way WebLogic maps SAML2 responses to WebLogic users. That is what the previous post covered.
I may go over the above steps in more detail some other time. Otherwise good luck on getting SSO in EPM :)
Subscribe to:
Posts (Atom)