Introduction
Sometime ago, we configured our Hyperion EPM for kerberos authentication. There are many documents, blogs which contain step-by-step kerberos SSO authentication. But during configuration I faced several issues and problems that were not explained in manuals, therefore I'm going to clarify configuration details. (this valid for Hyperion EPM 11.1.2.4 and weblogic 10.3.6)
1. Understanding of URL Policy conditions
During kerberos configuration you have to set up policies for URLs. It define access to the application URLs (for example /SmartViewProviders, /index.jsp and /* ). Every URL policies contains one or more policy condition:
But there are some features which everyone have to know in weblogic configuration:
There are two runtime groups in weblogic:
everyone - This group contains all anonymous users and, because it contains the users group, all users who have been authenticated.
users - This group contains all users who have been authenticated.
When user requests URL (for example /index.jsp), weblogic puts user in the everyone and check access for all policy conditions which not requires authentication. And condition policy order ignores, therefore if your conditions are not user or group condition user stays in everyone group and gets URL without kerberos request and it can't be authenticated in Hyperion EPM.
For example: if you set only one URL policy /* for workspace which allow access to everyone or by IP (PC name), you will not be authenticated and Hyperion show you login window. It is very important part of weblogic kerberos configuration.
If you use policy conditions: user or group weblogic uses kerberos for authentications and gets user token and user info (username, users domain groups), than it compares user credentials with conditions and allows access or not. In this way SSO successfully works.
Let's look at some examples1. Example with anonymous condition
Behavior: all requests from host hyperion_server are allowed, but SSO doesn't work, therefore user can't be authenticated in workspace.
2. Example with group conditions:
Behavior: URL access allowed for users from AD group, this will be resolved by kerberos SSO, therefore
user can be authenticated in workspace.
3. Example with both conditions:
Behavior: Order is not important, access for anonymous access checks first, than checks authorized access, these conditions allow access to everyone, but SSO doesn't works.
2. Example with group conditions:
Behavior: URL access allowed for users from AD group, this will be resolved by kerberos SSO, therefore
user can be authenticated in workspace.
3. Example with both conditions:
Behavior: Order is not important, access for anonymous access checks first, than checks authorized access, these conditions allow access to everyone, but SSO doesn't works.
2. How to allow native user access when SSO configured
We had mandatory requirement in kerberos projects: native users must have access to Hyperion Planning.
We need make some additional configuration:
- Set workspace property Allow direct logon after SSO failure = Yes
- Split URL policy for WORKSPACE deployment
/* - url must have only allow access to everyone condition
/index.jsp - url must have only group condition, to allow SSO
How to use it?
When you enter workspace using SSO (without login page), you have to log out from workspace, and login page will be accessible.
Good luck with SSO configuration!