I have recently had a chance to work with Oracle Platform Security Services. OPSS is a combination of application programming interfaces that provide abstraction layer over identity management implementations.
Before I go into details with OPSS, let me give you a quick background on the application that started using OPSS recently for user and role management purposes. The project is a custom built Spring based web application. The main purpose of the application is to provide services over our user repository which is Oracle Internet Directory. This application is responsible for providing user and role management. SpringLdap template was heavily used before it was replaced with OPSS through the application to query, and modify OID. The application is deployed to WebLogic Server 10.3.4. The current version of OID is 10.1.4.3 which is at the end of it support life and our client is considering moving away from it.
The fact that our client was thinking of migrating away from OID was a good enough reason for us to start thinking about integrating OPSS into our application. OPSS User and Role management API ensures that client is not aware of the underlying identity store or its type. OPSS provides user and role apis that can be used to search, and modify users and roles in underlying identity store without the client creating LDAP queries which is what was happening previously in our application with SpringLDAP. We were constructing dynamic LDAP queries and executing them through SpringLDAP template. This created a direct coupling of our application to the underlying identity store. OPSS provided that abstraction for us so that we could just call and api and let the implementation of the provider handle that. OPSS out of the box comes with many providers such as OID, OVD, AD, file, etc. Unlike other Oracle APIs it is also very extensible and you can provide your own providers easily if needed.
OPSS is also used through out the other Oracle products and it integrates nicely with WebLogic server which was the application server in our case. Once WebLogic security realm was configured with security authenticators, applications that are deployed can use the configuration. This for example eliminated a . properties file for us where we were storing credentials information for SpringLDAP. Limit to this approach however was that OPSS could only used the first authenticator in the list. WebLogic allows you to configure and chain many authenticators.
The other nice thing about OPSS is that it is not container dependent. It can run in a J2SE environment. All you need to do is provide an xml configuration file and use their APIs to access and build your identity store object.
One of the other features of the OPSS is that it also provides auditing capability which was very important for us as well. It actually can hook into Oracle Fusion Middleware Audit Framework and provide details about User and Role management events. We however quickly realized that there were a lot of short comings of this integration. OPSS for example could not audit role/user management events if the underlying identity store was OID or any other repository. It could audit role management if the application had policy controls which is also part of OPSS which our application was not using. In our case our integration to OPSS was at the service level and we wanted to use the User/Role API for abstraction purposes. We however ended up using Audit Framework directly to handle such audit events. Oracle's response to our recommendation to include this type of auditing was that OID and other user repositories provided their own auditing and newer versions of OID was already integrated with Audit Framework.
At the end, this was a very successful set up for us. We got rid of direct coupling with our application and the identity store. We got rid of .properties file that stored credentials and got a lot of cool benefits from WebLogic console integrated/configured authenticator. With our setting now using WebLogic console, we get monitoring benefits and ability to modify connection pooling etc.
Before I go into details with OPSS, let me give you a quick background on the application that started using OPSS recently for user and role management purposes. The project is a custom built Spring based web application. The main purpose of the application is to provide services over our user repository which is Oracle Internet Directory. This application is responsible for providing user and role management. SpringLdap template was heavily used before it was replaced with OPSS through the application to query, and modify OID. The application is deployed to WebLogic Server 10.3.4. The current version of OID is 10.1.4.3 which is at the end of it support life and our client is considering moving away from it.
The fact that our client was thinking of migrating away from OID was a good enough reason for us to start thinking about integrating OPSS into our application. OPSS User and Role management API ensures that client is not aware of the underlying identity store or its type. OPSS provides user and role apis that can be used to search, and modify users and roles in underlying identity store without the client creating LDAP queries which is what was happening previously in our application with SpringLDAP. We were constructing dynamic LDAP queries and executing them through SpringLDAP template. This created a direct coupling of our application to the underlying identity store. OPSS provided that abstraction for us so that we could just call and api and let the implementation of the provider handle that. OPSS out of the box comes with many providers such as OID, OVD, AD, file, etc. Unlike other Oracle APIs it is also very extensible and you can provide your own providers easily if needed.
OPSS is also used through out the other Oracle products and it integrates nicely with WebLogic server which was the application server in our case. Once WebLogic security realm was configured with security authenticators, applications that are deployed can use the configuration. This for example eliminated a . properties file for us where we were storing credentials information for SpringLDAP. Limit to this approach however was that OPSS could only used the first authenticator in the list. WebLogic allows you to configure and chain many authenticators.
The other nice thing about OPSS is that it is not container dependent. It can run in a J2SE environment. All you need to do is provide an xml configuration file and use their APIs to access and build your identity store object.
One of the other features of the OPSS is that it also provides auditing capability which was very important for us as well. It actually can hook into Oracle Fusion Middleware Audit Framework and provide details about User and Role management events. We however quickly realized that there were a lot of short comings of this integration. OPSS for example could not audit role/user management events if the underlying identity store was OID or any other repository. It could audit role management if the application had policy controls which is also part of OPSS which our application was not using. In our case our integration to OPSS was at the service level and we wanted to use the User/Role API for abstraction purposes. We however ended up using Audit Framework directly to handle such audit events. Oracle's response to our recommendation to include this type of auditing was that OID and other user repositories provided their own auditing and newer versions of OID was already integrated with Audit Framework.
At the end, this was a very successful set up for us. We got rid of direct coupling with our application and the identity store. We got rid of .properties file that stored credentials and got a lot of cool benefits from WebLogic console integrated/configured authenticator. With our setting now using WebLogic console, we get monitoring benefits and ability to modify connection pooling etc.
Comments
thank you so much.
Adnan
In our case we ended up using to replace Spring Ldap Template. As I tried to explain above, we had goals of moving away from our user repository. OPSS User Role API is object based and abstracts itself from the underlying repository. We thought it would get us ready for that goal. We no longer write ldap queries. We use OPSS User and Role objects to query and update the repository.
I did not find a step by step tutorial but you can try the link here http://docs.oracle.com/cd/E12839_01/core.1111/e10043/devuserole.htm#CIAEAHFE. There are code snippets there that show you how you can use the API to query and update the repository. You can also look at the JavaDocs that are located here http://docs.oracle.com/cd/E12839_01/doc.1111/e14658/toc.htm. Between the two we were able to quickly figure out how to use it.