Using Oracle Internet Directory (OID) as Identity store for OpenSSO
By user12601562 on Jun 14, 2009
1.0 Install and Configure Oracle Internet Directory OID
There are lot of resources available on the internet to install and configure the OID, I would suggest this article for the beginners on OID, found it very useful. For simplicity I have assumed OID is installed and configured with default settings with a root suffix dc=opensso,dc=java,dc=net. If your suffix is different from this you should change the suffix values appropriately in the respective files.
2.0 Preparing OID to be used as OpenSSO user store
This section includes two parts one describing on how to extend the OID schema to accommodate OpenSSO specific user attributes the other details about the special users and privileges required to manage the user store from OpenSSO perspective.
2.1 Extending the OID Schema
This is the critical part of the process with out this schema some of the user management features of OpenSSO cannot be achieved like the OpenSSO provided password reset feature or the user account lockout.
ldapmodify -h OID_HOST -p PORT -D "cn=orcladmin" -w PASSWD -f am_remote_oid_schema.ldif
2.2 Adding the privilege and the custom user entries
Since the OID schema is extended to include the OpenSSO attribute certain attributes of OpenSSO are critical from security point of view, normal users should not be able modify those attribute such as inetuserstatus, to prevent this self modification an ACI needs to be included in the OID configuration.
OID can be used as a profile,authentication and policy store, for
authentication and policy subjects read only permissions are enough.
For profile read and write permissions are required.
There will be a user created under the root suffix
dn: ou=opensso adminusers,dc=opensso,dc=java,dc=net
dn: cn=openssouser,ou=opensso adminusers,dc=opensso,dc=java,dc=net
dn: cn=RealmAdministrators, cn=Groups, cn=OracleContext,dc=opensso,dc=java,dc=net
In addition to the above you need to add appropriate ACI to prevent the self modification of certain security user attributes. This is not part of this procedure because adding this requires quite a bit of testing which I could not do it.
orclaci: access to attr=(objectclass,inetuserstatus,iplanet-am-user-login-status,iplanet-am-user-
-fm-saml2-nameid-infokey,sunAMAuthInvalidAttemptsData,memberof,member) by self (noselfwrite)
You should be able to download the above LDIF from here
Run the following command to load the LDIF
ldapmodify -h OID_HOST -p PORT -D "cn=orcladmin" -w PASSWD -f add_opensso_config_oid.ldif
Now your Oracle Internet Directory is ready to be used as a userstore for OpenSSO.
3.0 Create User data store in OpenSSO
Once the steps 1 through 2 are accomplished successfully you can go ahead
and create a new LDAPv3 type datastore pointing to the OID you have
just configured. I am going to show you the less error prone method to
create the user store that point to OID. I am assuming the ssoadm
command line tool is already confgured with your OpenSSO server.
You just need to run the following command
- ssoadm create-datastore -m "OID User Store" -t "LDAPv3" -D datastore_oid_attrs.txt -u amadmin -f /tmp/.pass_of_amadmin -e /
make sure you have replaced the OID server's name and port in the
datastore_oid_attrs.txt. Now you can start creating and managing
users that are stored in the OID server.
If you want to use this server as LDAP authentication source, you
configure the LDAP auth instance with the bind user cn=ldapuser, like
wise for the policy configuration service.
4.0 Removing the OpenSSO schema from OID
At some point if you want to remove the schema and the adminstrative entries along with the privileges added by the section 2.2, you can simply run the following command
This will remove the OpenSSO user schema.
This will remove the ACIs and the administrative users like cn=openssouser from the Oracle Internet Directory.
- Persistent search control is not supported by OID so the change notification will not be happening at the OpenSSO side, you need to wait for the cache time out.
Password polcies, extensive group management yet to be validated, however the static groups seems to be working fine in my testing