Part 1 – The Theory
Nowadays huge Oracle-projects are going on where we are implementing technical solutions which are adding value to our business. Everything must be faster, easier and more agile. For these reasons many applications and functionalities are currently under the flag of Oracle but how do you make them collaborate and communicate with each other? How do you make sure all communication is safe and assigned to the right identity? And when you manage to make it all collaborate, how do you ever remind all the passwords you’ve entered and is it possible to prevent re-entering them for other applications?
You can watch this Oracle movie about the effect of multiple passwords for an end-user.
In most of the business cases Single Sign-On is not the key-functionality to start an Oracle project. However almost all Oracle implementations contain some Single Sign-On functionality. A part which is mostly mentioned at the end analyzing the requirements. Why is this mostly the forgotten or underestimated part? It shouldn’t be that difficult to connect those applications to each other, it is all based on JAVA and XML isn’t it?
For this easy and time-saving feature you need to think about how the connection between different applications is established. First of all you need to know which applications on which application-servers should be in the Single Sign-On scope. After that you want to know where they are currently keeping their identity data¹ and if this matches the preferred situation for Single Sign-On. With Oracle there are many different ways to realize Single Sign-On. You can do it for one single application but you can also do it for the whole application server. Weblogic for instance has even some out of the box Single Sign-On functionalities. For more advanced features Oracle has a variety of products which can help you out:
- Oracle Access Manager (Which can setup access management between multiple applications)
- Oracle Adaptive Access Manager (Which has an extended range of authorization possibilities)
- Oracle Enterprise Single Sign-On Suite (Which is a dedicated Single Sign-On suite)
- Oracle Security Token Service (Which handles Single Sign-On using security tokens)
- Oracle Identity Federation (Which handles Single Sign-On with 3th party organizations and domains)
From scope to action
For deciding which solution is best for your company, you need to specify the scope of your Single Sign-On requirement during the requirement analyses. The following example explains a situation of Oracle Single Sign-On which we handled lately.
“The new “Oracle Webcenter” Intranet portal and “Oracle Webcenter Content” must be accessible using only the Windows Native Active authentication for accessing the Windows domain. There is already a Kerberos-server in place which can create login-tickets to create sessions.”
For this situation we did the following actions:
– On the Weblogic server there is an out of the box solution for this. You can use the “Negotiate Identity Assertion Provider” which is an addition to the Weblogic security realm you are using. Identity Assertion providers enable perimeter authentication and support single sign-on. This provider connects Weblogic to Kerberos just to check your session status. Kerberos is linked to the Identity store (Active Directory). You can install and configure this provider in the Weblogic security realm configuration.
– You also need a connection with “Oracle Internet Directory” which is the policy and credential store in this situation. OID is used to add some additional information to a user account in Active Directory. Weblogic also has an out of the box provider to connect to OID. This “OID Authenticator Provider” must also be installed in the security realm you are using to establish the connection.
– After that you need to create a service principal in Active Directory which is used by Weblogic and Kerberos to create session-tickets. Note that this is not an ordinary user in Active Directory. This user has for instance no password expiry. So an application can use this “principal” for connecting to Active Directory. You need to configure Weblogic to use this “Service Principal” by editing a “JAAS-file”.
– Besides editing the “JAAS -file” for the service principal, you also need to edit the “krb5.conf” file which is used to connect to your Windows domain and the Kerberos server. After editing those files you also need to configure Weblogic to use them. This can be done in the “setDomainEnv.sh” file which is used to startup the Weblogic server.
All together makes enabling Single Sign-On a time-consuming and high technical job which can better not be underestimated. It is best to involve this piece of functionality to your requirements analyses to prevent unexpected costs at the end of the project. We as Capgemini can help you define your Single Sign-On scope so that you can prevent these unexpected costs. We can also configure your environment to get the best results with single sign-on.
This was in theory an example of how to enable single sign-on with Oracle. In part 2 we are explaining the practical implementation and all the issues we have faced.
So stay tuned on the Oracle blog!
¹In some cases an organization has multiple identity stores and you may want to combine them to one virtual identity store. Oracle Virtual Directory can help you solving this problem.