Using OpenDS as a User Data Store in OpenSSO Express 7

This article provides instructions for installing and configuring OpenDS to store user profiles, authentication data, and policies.
When configuring OpenDS as a user store for OpenSSO Express 7, keep the following in mind:

  • OpenSSO Express 7 doesn't support the extensive password policy features provided by OpenDS.
  • Only static groups are supported from the OpenSSO console for now.

Before You Begin

  • Before following the instructions in this article, an OpenSSO Express 7 server must be already installed and configured on a supported web container.
  • Creating a user data store using the OpenSSO Configurator is not supported in OpenSSO Express 7.
  • Static groups with the member and uniquemember attributes have been tested and work as designed.
    If you use these attributes, then you must add the groupOfNames object class to the User Data Store Configuration page.
  • Testing is in progress for groups with other (virtual) attributes such as member, memberof,  and ismemberof.
  • The Referential Integrity plug-in must be enabled in the OpenDS.
    The Referential  Integrity plug-in ensures that when the groups are removed from the directory, all references in the users' entries are removed automatically. If the Referential Integrity plug-in is not enabled,  you will see deleted groups displayed the users' profiles even after the group has been removed from the directory server.

To use OpenDS as the OpenSSO Express 7 user data store, complete these steps.  Detailed instructions are provided in the following sections.

  1. Download and install OpenDS.
  2. Add the OpenSSO Express 7 schema and supporting OpenDS user management data to OpenDS..
  3. Configure OpenSSO Express 7 to Use OpenDS as the User Data Store.

To Download and Install OpenDS

  1. Download an OpenDS build from the following website: http://www.opends.org/promoted-builds/
  2. Follow the instructions in the OpenDS Installation Guide.
  3. Enable the OpenDS Referential Integrity plug-in.  See  Maintaining Referential Integrity in the OpenDS Installation Guide.

To Add the OpenSSO Express 7 Schema and Supporting OpenDS User Management Data to OpenDS

OpenSSO Express 7 leverages certain LDAPv3-compliant attributes.  Additionally, other objectclasses and user attributes are required and must be added to OpenDS to take full advantage of OpenSSO's functionality.

User schema is contained in the following file: <opensso_configuration_directory>/am_remote_opends_schema.ldif

  1. To load the schema, run the following command:
    ldapmodify -h <opends_host> -p <opends_port> 
         -D"RootDN" -w <RootDN_password> -c -f am_remote_opends_schema.ldif
    
  2. To load the configuration for the openssouser and ldapuser users, special users required by OpenSSO, do the following:
    1. Download the text contained in the file configure_opends_userstore.ldif to a local file named configure_opends_userstore.ldif on your system.
    2. Edit the the following:
      • Change ROOT_SUFFIX to the root suffix of your user directory
      • Change OPENSSO_USER_PASSWD to a password for the openssouser user
      • Change LDAP_USER_PASSWD to a password for the ldapuser user
      • Save the file.
    3. Run the following command:
      ldapmodify -h <opends_host> -p <opends_port> -D"RootDN" -w <RootDN_password> -c
        -a  -f  configure_opends_userstore.ldif
      

Configuring OpenSSO Express 7 to Use OpenDS as the User Data Store

Once you have configured OpenDS, you can configure OpenSSO Express 7 to work with OpenDS.  Complete the following steps. Detailed instructions are provided in the following sections:

  1. Create a new LDAPv3-compliant user data store.
    You can use the command-line interface or use the OpenSSO Express 7 Administration Console.
  2. Add OpenSSO Express 7 object classes and user attributes to the user data store.
  3. (Optional) Remove the OpenSSO Express 7 schema from OpenDS.

To Create a New LDAPv3-compliant User Data Store at the Command Line

The ssoadm command line tool must  already be configured in the OpenSSO Express 7 server.

  1. Log into the OpenSSO Express 7 host.
  2. Download the text in the Example to a local file named datastore_opends_attrs.txt on you system. Modify the file as needed for your deployment. Be sure to replace the default OpenDS server name and port number with your OpenDS server name and port number.  In the following example, the root suffix is dc=opensso,dc-Java,dc=net
    Example
    com.iplanet.am.ldap.connection.delay.between.retries=1000
    RequiredValueValidator=
    sun-idrepo-ldapv3-config-active=Active
    sun-idrepo-ldapv3-config-auth-naming-attr=uid
    sun-idrepo-ldapv3-config-authenticatable-type=User
    sun-idrepo-ldapv3-config-authid=cn=openssouser,ou=opensso adminusers,dc=opensso,dc=java,dc=net
    sun-idrepo-ldapv3-config-authpw=amsecret12
    sun-idrepo-ldapv3-config-cache-enabled=false
    sun-idrepo-ldapv3-config-cache-size=10240
    sun-idrepo-ldapv3-config-cache-ttl=600
    sun-idrepo-ldapv3-config-connection_pool_max_size=10
    sun-idrepo-ldapv3-config-connection_pool_min_size=1
    sun-idrepo-ldapv3-config-createuser-attr-mapping=cn
    sun-idrepo-ldapv3-config-createuser-attr-mapping=sn
    sun-idrepo-ldapv3-config-dftgroupmember=
    sun-idrepo-ldapv3-config-errorcodes=80
    sun-idrepo-ldapv3-config-errorcodes=81
    sun-idrepo-ldapv3-config-errorcodes=91
    sun-idrepo-ldapv3-config-filterrole-attributes=
    sun-idrepo-ldapv3-config-filterrole-objectclass=
    sun-idrepo-ldapv3-config-group-attributes=cn
    sun-idrepo-ldapv3-config-group-attributes=description
    sun-idrepo-ldapv3-config-group-attributes=dn
    sun-idrepo-ldapv3-config-group-attributes=iplanet-am-group-subscribable
    sun-idrepo-ldapv3-config-group-attributes=objectclass
    sun-idrepo-ldapv3-config-group-attributes=ou
    sun-idrepo-ldapv3-config-group-attributes=uniqueMember
    sun-idrepo-ldapv3-config-group-container-name=ou
    sun-idrepo-ldapv3-config-group-container-value=groups
    sun-idrepo-ldapv3-config-group-objectclass=groupofuniquenames
    sun-idrepo-ldapv3-config-group-objectclass=iplanet-am-managed-group
    sun-idrepo-ldapv3-config-group-objectclass=iplanet-am-managed-static-group
    sun-idrepo-ldapv3-config-group-objectclass=top
    sun-idrepo-ldapv3-config-groups-search-attribute=cn
    sun-idrepo-ldapv3-config-groups-search-filter=(objectclass=groupOfUniqueNames)
    sun-idrepo-ldapv3-config-idletimeout=0
    sun-idrepo-ldapv3-config-inactive=Inactive
    sun-idrepo-ldapv3-config-isactive=inetuserstatus
    
    sun-idrepo-ldapv3-config-ldap-server=<hostName.domain:portNumber>
    
    sun-idrepo-ldapv3-config-max-result=1000
    sun-idrepo-ldapv3-config-memberof=
    sun-idrepo-ldapv3-config-memberurl=memberUrl
    sun-idrepo-ldapv3-config-nsrole=
    sun-idrepo-ldapv3-config-nsroledn=
    sun-idrepo-ldapv3-config-nsrolefilter=
    sun-idrepo-ldapv3-config-numretires=3
    sun-idrepo-ldapv3-config-organization_name=dc=opensso,dc=java,dc=net
    sun-idrepo-ldapv3-config-people-container-name=ou
    sun-idrepo-ldapv3-config-people-container-value=people
    sun-idrepo-ldapv3-config-psearch-filter=(objectclass=*)
    sun-idrepo-ldapv3-config-psearch-scope=SCOPE_SUB
    sun-idrepo-ldapv3-config-psearchbase=dc=opensso,dc=java,dc=net
    sun-idrepo-ldapv3-config-referrals=true
    sun-idrepo-ldapv3-config-search-scope=SCOPE_ONE
    sun-idrepo-ldapv3-config-service-attributes=
    sun-idrepo-ldapv3-config-ssl-enabled=false
    sun-idrepo-ldapv3-config-time-limit=10
    sun-idrepo-ldapv3-config-uniquemember=uniqueMember
    sun-idrepo-ldapv3-config-user-attributes=adminRole
    sun-idrepo-ldapv3-config-user-attributes=authorityRevocationList
    sun-idrepo-ldapv3-config-user-attributes=caCertificate
    sun-idrepo-ldapv3-config-user-attributes=cn
    sun-idrepo-ldapv3-config-user-attributes=distinguishedName
    sun-idrepo-ldapv3-config-user-attributes=dn
    sun-idrepo-ldapv3-config-user-attributes=employeeNumber
    sun-idrepo-ldapv3-config-user-attributes=facsimileTelephoneNumber
    sun-idrepo-ldapv3-config-user-attributes=givenName
    sun-idrepo-ldapv3-config-user-attributes=homePhone
    sun-idrepo-ldapv3-config-user-attributes=homePostalAddress
    sun-idrepo-ldapv3-config-user-attributes=inetUserHttpURL
    sun-idrepo-ldapv3-config-user-attributes=inetUserStatus
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-auth-configuration
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-add-session-listener-on-all-sessions
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-destroy-sessions
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-get-valid-sessions
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-max-caching-time
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-max-idle-time
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-max-session-time
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-quota-limit
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-session-service-status
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-static-group-dn
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-account-life
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-admin-start-dn
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-alias-list
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-auth-config
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-auth-modules
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-failure-url
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-federation-info
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-federation-info-key
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-login-status
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-password-reset-force-reset
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-password-reset-options
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-password-reset-question-answer
    sun-idrepo-ldapv3-config-user-attributes=iplanet-am-user-success-url
    sun-idrepo-ldapv3-config-user-attributes=mail
    sun-idrepo-ldapv3-config-user-attributes=manager
    sun-idrepo-ldapv3-config-user-attributes=memberOf
    sun-idrepo-ldapv3-config-user-attributes=mobile
    sun-idrepo-ldapv3-config-user-attributes=ds-pwp-account-disabled
    sun-idrepo-ldapv3-config-user-attributes=objectClass
    sun-idrepo-ldapv3-config-user-attributes=pager
    sun-idrepo-ldapv3-config-user-attributes=postalAddress
    sun-idrepo-ldapv3-config-user-attributes=postofficebox
    sun-idrepo-ldapv3-config-user-attributes=preferredlanguage
    sun-idrepo-ldapv3-config-user-attributes=preferredLocale
    sun-idrepo-ldapv3-config-user-attributes=preferredtimezone
    sun-idrepo-ldapv3-config-user-attributes=secretary
    sun-idrepo-ldapv3-config-user-attributes=sn
    sun-idrepo-ldapv3-config-user-attributes=street
    sun-idrepo-ldapv3-config-user-attributes=sun-fm-saml2-nameid-info
    sun-idrepo-ldapv3-config-user-attributes=sun-fm-saml2-nameid-infokey
    sun-idrepo-ldapv3-config-user-attributes=sunAMAuthInvalidAttemptsData
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityMSISDNNumber
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerDiscoEntries
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPAddressCard
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNameAltCN
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNameCN
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNameFN
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNameMN
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNamePT
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPCommonNameSN
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPDemographicsAge
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPDemographicsBirthDay
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPDemographicsDisplayLanguage
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPDemographicsLanguage
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPDemographicsTimeZone
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPEmergencyContact
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPEmploymentIdentityAltO
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPEmploymentIdentityJobTitle
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPEmploymentIdentityOrg
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPEncryPTKey
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPFacadegreetmesound
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPFacadeGreetSound
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPFacadeMugShot
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPFacadeNamePronounced
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPFacadeWebSite
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPInformalName
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityAltIdType
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityAltIdValue
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityDOB
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityGender
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityLegalName
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityMaritalStatus
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityVATIdType
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPLegalIdentityVATIdValue
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPMsgContact
    sun-idrepo-ldapv3-config-user-attributes=sunIdentityServerPPSignKey
    sun-idrepo-ldapv3-config-user-attributes=telephoneNumber
    sun-idrepo-ldapv3-config-user-attributes=uid
    sun-idrepo-ldapv3-config-user-attributes=userCertificate
    sun-idrepo-ldapv3-config-user-attributes=userPassword
    sun-idrepo-ldapv3-config-user-objectclass=inetadmin
    sun-idrepo-ldapv3-config-user-objectclass=inetorgperson
    sun-idrepo-ldapv3-config-user-objectclass=inetUser
    sun-idrepo-ldapv3-config-user-objectclass=iplanet-am-managed-person
    sun-idrepo-ldapv3-config-user-objectclass=iplanet-am-user-service
    sun-idrepo-ldapv3-config-user-objectclass=iPlanetPreferences
    sun-idrepo-ldapv3-config-user-objectclass=organizationalPerson
    sun-idrepo-ldapv3-config-user-objectclass=person
    sun-idrepo-ldapv3-config-user-objectclass=sunFederationManagerDataStore
    sun-idrepo-ldapv3-config-user-objectclass=sunFMSAML2NameIdentifier
    sun-idrepo-ldapv3-config-user-objectclass=sunIdentityServerLibertyPPService
    sun-idrepo-ldapv3-config-user-objectclass=top
    sun-idrepo-ldapv3-config-users-search-attribute=uid
    sun-idrepo-ldapv3-config-users-search-filter=(objectclass=inetorgperson)
    sun-idrepo-ldapv3-ldapv3Generic=
    sunIdRepoAttributeMapping=
    sunIdRepoClass=com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo
    sunIdRepoSupportedOperations=group=read,create,edit,delete
    sunIdRepoSupportedOperations=realm=read,create,edit,delete,service
    sunIdRepoSupportedOperations=user=read,create,edit,delete,service
    
  3. Run the following command:
    ssoadm create-datastore -m "OpenDS User Store" -t "LDAPv3" -D datastore_opends_attrs.txt
      -u amadmin -f /tmp/.pass_of_amadmin  -e /
    

    The file .pass_of_amadmin contains the amadmin user's password in plain text.

  4. (Optional)To use this server as the LDAP authentication source:
    1. Configure the LDAP authentication instance with the bind user cn=ldapuser.
    2. Configure the policy configuration service with the bind user cn=ldapuser.

To Create a New LDAPv3-compliant User Data Store Using the OpenSSO Express 7 Administration Console

  1. Log in to the OpenSSO Express 7 administration console.
  2. Click the Access tab, an then Top-level Realm > Data Stores.
  3. On the Data Stores tab, click the Generic LDAP v3 user data store.
  4. On the Generic LDAP v3 data store page, add the LDAP User object classes and attributes.
    1. If they do not already exist, add the following LDAP User Object Classes:
      inetadmin
      inetorgperson
      inetUser
      iplanet-am-managed-person
      iplanet-am-user-service
      iPlanetPreferences
      organizationalPerson
      person
      sunFederationManagerDataStore
      sunFMSAML2NameIdentifier
      sunIdentityServerLibertyPPService
      top
      
    2.  If they do not already exist, add the following LDAP User Attributes:
      adminRole
      authorityRevocationList
      caCertificate
      cn
      distinguishedName
      dn
      ds-pwp-account-disabled
      employeeNumber
      facsimileTelephoneNumber
      givenName
      homePhone
      homePostalAddress
      inetUserHttpURL
      inetUserStatus
      iplanet-am-auth-configuration
      iplanet-am-session-add-session-listener-on-all-sessions
      iplanet-am-session-destroy-sessions
      iplanet-am-session-get-valid-sessions
      iplanet-am-session-max-caching-time
      iplanet-am-session-max-idle-time
      iplanet-am-session-max-session-time
      iplanet-am-session-quota-limit
      iplanet-am-session-service-status
      iplanet-am-static-group-dn
      iplanet-am-user-account-life
      iplanet-am-user-admin-start-dn
      iplanet-am-user-alias-list
      iplanet-am-user-auth-config
      iplanet-am-user-auth-modules
      iplanet-am-user-failure-url
      iplanet-am-user-federation-info
      iplanet-am-user-federation-info-key
      iplanet-am-user-login-status
      iplanet-am-user-password-reset-force-reset
      iplanet-am-user-password-reset-options
      iplanet-am-user-password-reset-question-answer
      iplanet-am-user-success-url
      mail
      manager
      memberOf
      mobile
      objectClass
      pager
      postalAddress
      postofficebox
      preferredlanguage
      preferredLocale
      preferredtimezone
      secretary
      sn
      street
      sunAMAuthInvalidAttemptsData
      sun-fm-saml2-nameid-info
      sun-fm-saml2-nameid-infokey
      sunIdentityMSISDNNumber
      sunIdentityServerDiscoEntries
      sunIdentityServerPPAddressCard
      sunIdentityServerPPCommonNameAltCN
      sunIdentityServerPPCommonNameCN
      sunIdentityServerPPCommonNameFN
      sunIdentityServerPPCommonNameMN
      sunIdentityServerPPCommonNamePT
      sunIdentityServerPPCommonNameSN
      sunIdentityServerPPDemographicsAge
      sunIdentityServerPPDemographicsBirthDay
      sunIdentityServerPPDemographicsDisplayLanguage
      sunIdentityServerPPDemographicsLanguage
      sunIdentityServerPPDemographicsTimeZone
      sunIdentityServerPPEmergencyContact
      sunIdentityServerPPEmploymentIdentityAltO
      sunIdentityServerPPEmploymentIdentityJobTitle
      sunIdentityServerPPEmploymentIdentityOrg
      sunIdentityServerPPEncryPTKey
      sunIdentityServerPPFacadegreetmesound
      sunIdentityServerPPFacadeGreetSound
      sunIdentityServerPPFacadeMugShot
      sunIdentityServerPPFacadeNamePronounced
      sunIdentityServerPPFacadeWebSite
      sunIdentityServerPPInformalName
      sunIdentityServerPPLegalIdentityAltIdType
      sunIdentityServerPPLegalIdentityAltIdValue
      sunIdentityServerPPLegalIdentityDOB
      sunIdentityServerPPLegalIdentityGender
      sunIdentityServerPPLegalIdentityLegalName
      sunIdentityServerPPLegalIdentityMaritalStatus
      sunIdentityServerPPLegalIdentityVATIdType
      sunIdentityServerPPLegalIdentityVATIdValue
      sunIdentityServerPPMsgContact
      sunIdentityServerPPSignKey
      telephoneNumber
      uid
      userCertificate
      userPassword
      
  5.  Click Save.

To Remove the OpenSSO Express 7 schema from OpenDS

At some point if you want to remove the schema you added to OpenDS in these instructions,  log into the OpenDS host and run the following command

ldapmodify -h <opends-host> -p <opends_port> -D"cn=directory manager" -w <password> -c
  -f  remove_am_remote_opends_schema.ldif

This will remove the OpenSSO Express 7 user schema.  See https://opensso.dev.java.net/source/browse/opensso/products/amserver/war/ldif/remove_am_remote_opends_schema.ldif?rev=1.1&view=log

Troubleshooting

When an administrator tries to change a user's password using the OpenSSO Express 7 console or CLI or using the ldap-modifyutility, if the following message is displayed in the OpenDS access log: "You do not have sufficient privileges to reset user passwords, " then the password-reset privilege is not configured.

In OpenDS, you must add the password-reset privilege and assign it to an administrator.  In the following example, the administrator is  named openssouser. This privilege enables the administrator to reset the passwords of other users in the directory. The password-reset privilege works in association with the OpenDS ACIs that are set in the target.

About the OpenSSO Express 7 User Data Store

OpenSSO Express 7 uses an identity repository to store user data such as users and groups. During OpenSSO Express 7 installation, you must specify which user data store you want to use. For example, you can use Sun Directory Server Enterprise Edition, Microsoft Active Directory, IBM Tivoli, or OpenDS.

Use the tables in this section to help you determine which user data store meets your needs.

In the following table, a Policy Subject refers to the "who" part of the policy definition. The Policy Subject specifies the members or entities to
which the policy applies. Policy Condition refers to the additional restrictions with which the policy applies. Examples are a specified window of time in a day, a specified IP address, or a specified authentication method.

Table 2-1 Supported Features for Various Directory Servers
OpenSSO Express 7 Feature Sun Directory Server LDAPv3 OpenDS Microsoft Active Directory LDAPv3 IBM Tivoli Directory Generic LDAPv3
User Data Storage Yes Yes Yes Yes No
Configuration Data Storage Yes Yes No No No
AMSDK (legacy) Yes No No No No
LDAP Authentication Yes Yes Yes Yes Yes
Membership Authentication Yes Yes No Yes No
Active Directory Authentication Not Applicable Not Applicable Yes, with limitations Not Applicable Not Applicable
Policy Subjects and Policy LDAP Filter Condition Yes Yes Yes Yes Yes
Password Reset Yes  Yes  No No No
Account Lockout Yes Yes No Yes No
Cert Authentication Yes Yes Yes Yes Yes
MSISDN Authentication Yes Yes Yes Yes Yes
Data Store Authentication (through LDAPv3 user store configuration) Yes Yes Yes Yes Yes
User creation with Password and Password Management Yes Yes No Yes Yes
Password Policy
Yes
Limited support
No
No
No

The following table summarizes the user management operations supported through the IDRepo interface for various user data stores. An interface has been implemented specifically for Sun Directory Server and Microsoft Active Directory. The
default implementation of this interface can be used and supported for any LDAPv3 user repository.

Table 2-2 Data Stores and Supported Operations
Feature Sun Directory Server LDAPv3 OpenDS Microsoft Active Directory LDAPv3 IBM Tivoli Directory AMSDK (Legacy)
Create User Yes Yes Yes* Yes Yes
Modify User Yes Yes Yes* Yes Yes
Delete User Yes Yes Yes* Yes Yes
Create Role Yes No No No Yes
Modify Role Yes No No No Yes
Delete Role Yes No No No Yes
Assign Role Yes No No No Yes
Evaluate Role for Membership Yes No No No Yes
Create Group Yes Yes Yes* Yes** Yes
Modify Group Yes Yes Yes* Yes** Yes
Delete Group Yes Yes Yes* Yes** Yes
Evaluate Group for Membership Yes Yes Yes* Yes** Yes
Federation Attributes Yes Yes Yes Yes Yes

*Some limitations exist, or additional configuration is required.

** See limitations in the next section "Additional Information About Using IBM Tivoli Directory Server Configured as the IDRepo Data Store."

Additional Information About Using IBM Tivoli Directory Server Configured as the IDRepo Data Store

IBM Tivoli Directory Server's groups can be Static, Dynamic, and Nested. However, the OpenSSO Express 7 IDRepo framework (IDRepo DataStore) supports only the
Static group. A Static group defines each member individually using either of the following:

  • Structural ObjectClass: groupofNames, {{ groupOfUniqueNames}}, accessGroup, or accessRole
  • Auxilary ObjectClass: ibm-staticgroup or ibm-globalAdminGroup

A Static group using the Structural ObjectClass groupOfNames and groupOfUniqueNames requires at least one member for ObjectClass groupOfNames or one uniquemember for groupOfUniqueNames. The Static group using the ObjectClass ibm-staticgroup does not have this requirement. The ObjectClass ibm-staticgroup is the only ObjectClass for which members are optional; all other object classes require at least one member.

OpenSSO Express 7 supports only one ObjectClass for groups. If you choose a type of group with an ObjectClass that requires at leas one member, then a user value must be present. This user will automatically be added to the group when a group is created. You can remove this user from the group afterward if you don't
want this user to be a member of the group.

The value for the filter for searching of groups must the value specified by the chosen LDAP Group ObjectClass.

Most IBM Tivoli groups require at least one member when the group is created. When a group is created using the OpenSSO Express 7 console, no users are assigned to the group by default. Since IBM Tivoli has this restriction, when a group is created, the default user or member cn=auser1,dc=opensso,dc=java,dc=net is always automatically created and added to the group.

Additional Information for Determining Which User Data Store to Use

  • Account Lockout locks a user account based on the policies defined in the Directory Server.
    For example, the user account can be locked when a specified number of login failures occurs.
  • The key difference between using a policy LDAP subject and the IDRepo interface subject is that policy LDAP subjects don't provide caching and notification updates. The AMIdentity Subject does provide caching an notification updates.
    The policy LDAP subjects provide LDAP Organization, Role (if Sun Directory Server), Group, and User subjects to evaluate membership of a user and determine if
    the user belongs to one of these subjects. The same result can be obtained using the Identity Repository (IDRepo) interface subject named AMIdentity Subject. This interface subject was introduced when the product was named Access Manager 7.0. You can develop a policy subject for a JDBC user store. Authentication also supports the JDBC repository through the JDBC authentication module.
  • The IDRepo interface provides basic user management features for user, group,
    role, and Access Manager policy agent entities.
    This interface enables OpenSSO Express 7 to support any user repository through the development of new plug-ins. Although limited to Sun Directory Server, Microsoft Active Directory, and IBM Tivoli Directory today, the IDRepo interface could potentially be expanded to include any LDAPv3 directory server such as OpenLDAP or Novel Directory for JDBC, flat files, and so forth.
  • Prior to Access Manager 7.0, user management was supported using Access Manager object classes and attributes in addition to using specific features from Sun
    Directory Server. This support still exists through the legacy AMSDK interface.
    But this support is deprecated and will be removed future releases.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 08

    timothywebster says:

    I am a little confused. My understanding is that opensso's embedded id repositor...

    I am a little confused. My understanding is that opensso's embedded id repository is opends but is not recommended for production environments. What are the problems that are solved by using a standalone instance of opends, and how is the opends configuration described in this article different from the configuration of the embedded opends instance?

    1. Jun 08

      ginac says:

      The embedded OpenDS is primarily meant for storing the OpenSSO configuration and...

      The embedded OpenDS is primarily meant for storing the OpenSSO configuration and policy data, and not for storing user data. If you want to use OpenDS in production, then using an external or standalone OpenDS would be a more scalable and performance-efficient option.

      1. Jun 09

        timothywebster says:

        I understand that conceptually, but I wondered what specific differences I shoul...

        I understand that conceptually, but I wondered what specific differences I should expect between standalone and embedded OpenDS. For example, maybe the embedded OpenDS can't be set up in a load balanced or fault tolerant configuration? Is that the kind of thing that makes standalone more scalable and performance efficient?

        1. Jun 15

          metadaddy says:

          One big difference is that the embedded instance of OpenDS shares a Java virtual...

          One big difference is that the embedded instance of OpenDS shares a Java virtual machine with OpenSSO. This places limits on its scalability and flexibility of deployment compared with a standalone OpenDS.

          A standalone instance of OpenDS:

          1. Will have its own Java virtual machine - it gets the entire address space for its own use, and the VM may be tuned specifically for OpenDS' requirements
          2. May be deployed on a different machine from OpenSSO - OpenDS will have more processing power at its disposal
          3. May serve identity data to applications other than OpenSSO
  2. Jun 22

    ahnjoan says:

    I've followed the above instructions and notice that after completion, the attri...

    I've followed the above instructions and notice that after completion, the attribute "memberof" is only added to the embedded data store when adding a user to a group and not to the new user data store. I also noticed that the "Admin" group is no longer viewable within the console. Would appreciate anyone's thoughts on these two issues.

    Thanks
    Ahnjoan

    1. Jul 02

      ginac says:

      Ahnjoan, I forwarded your questions (posted elsewhere) to one of our QA staff. ...

      Ahnjoan,
      I forwarded your questions (posted elsewhere) to one of our QA staff. See his comments inline:

      After configuring an additional user store...

      1. The attribute "memberof" is only written to the users entry in the
      embedded user store and not to a users entry in the new user store.

      > If this can be modified, where do you modify this behavior?
      if it is writing to the embedded store then the config look right, just delete the embedded user store and try with only the external user store

      2. Each user in the new user store is given inetadmin objectclass, I
      can't say this is wrong but it seems to me "plain" users shouldn't
      have the word "admin" in any attribute by default. Did I do something
      wrong to make this happen?

      > It is correct, not sure why you are saying that inetadmin obj class cannot be there in the user entry, but if you want to manage users from opensso console then the inetadmin obj class is must as we rely on the inetuserstatus attribute

      3. The default group "Admin" no longer shows up in the console. This
      is the group that amadmin belongs to and its defined in the embedded
      store under services but can no longer be viewed under groups using
      the console.

      > Look at the groups search filter in the datastore config page , may be it has the wrong filter

      4. It seems that everything added to the new user store also gets
      added to the embedded store. I though the reason for having a
      separate data store for the users was to alleviate some performance
      impact of having the users in the embedded directory. If that is the
      purpose, is this the expected behaviour or did I configure something
      incorrectly?

      > The behaviour is correct, if you dont want the user to be added in a user store just remove the permission user=write from the datastore config page

  3. Jun 24

    VnextKris says:

    Is there any particular reason that the following operations are not supported u...

    Is there any particular reason that the following operations are not supported using OpenDS as the data store:

    Create Role
    Modify Role
    Delete Role
    Assign Role
    Evaluate Role for Membership

    Surely these are fairly key requirements that won't be met by the embedded OpenDS store?

    I'd like to use a seperate installation of OpenDS as our directory, but with these features lacking I'm wondering whether thats a good idea or not?

    1. Jun 25

      inthanga says:

      OpenDS does not directly support Roles, however there is a way to achieve the sa...

      OpenDS does not directly support Roles, however there is a way to achieve the same functionality, you need to configure the OpenDS using this https://www.opends.org/wiki/page/SimulatingDSEERolesInOpenDS instruction. This is beyond the scope of OpenSSO.

  4. Jul 22

    ahnjoan says:

    Ginac - Thank you very much for forwarding on my questions and posting the answe...

    Ginac - Thank you very much for forwarding on my questions and posting the answers. I'm having a very hard time getting this to work so I've removed all opensso and opends software from our development environment and followed the directions exactly as they are written. From this i have few additional questions.

    The following questions apply to the section titled "To Create a New LDAPv3-compliant User Data Store at the Command Line" in the directions.
    1. Item number four, sub item a
    Is this modification completed to the LDAP "module" on the "Authentication" tab?
    If so should the instructions include removing the embedded directory value from the "current values" of the "Primary LDAP Server" and adding the new directory in its place?
    Is there a way to do this on the command line?

    2. Item number four, sub item b
    Is this modification completed to the policy configuration service on the "Services" tab?
    If so should the instructions include removing the embedded directory value from the "current values" of the "Primary LDAP Server" and adding the new directory in its place?
    Is there a way to do this on the command line?

    Assuming the above questions are all answered in the affirmative I have the following problems.

    1. Users added to the new OpenDS directory do not show up in the subjects->user tab.
    2. New users created in the OpenSSO GUI are only created in the embedded directory (before I remove the embedded data store from the gui)
    3. Attempting to remove the embedded store in the GUI causes the following failures
    When attempting to create a user in the GUI or attempting to access the Privileges tab results in "Plug-in com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo encountered an ldap exception. LDAP Error 49: The credentials presented to the server for authentication are not valid."
    Clicking on a user in the Subjects->Users tab, and then browsing a single users group tab results in the following error. "There is no information to display for this entry."

    I'm assuming I just have not completed a step that the directions take for granted that I should have. I have started this process from beginning to end three times in an orderly (scripted as much as possible to eliminate error on my end) and get the same results each time. NOTHING other than what is in the directions has been done.

    Thanks
    Ahnjoan

    1. Jul 22

      ahnjoan says:

      Please disregard the above post. If you happen to be experiencing the same thin...

      Please disregard the above post. If you happen to be experiencing the same things I was please check the following.

      1. The full DN is entered for ldapuser in the authentication LDAP module "DN for Root User Bind" entry
      2. The full DN is entered for ldapuser in the policy configuration service "LDAP Bind DN" entry

      Thanks to Indira Thangasamy for answering this same issue that Krishna Kumar posted. Apologies for not finding it on the mailing list before I posted here.

      Thanks
      Ahnjoan

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Sun Microsystems community and they might not be employed or in any way formally affiliated with Sun Microsystems. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Sun nor any other party necessarily agrees with them.

Copyright 1994-2009 Sun Microsystems, Inc.
Powered by Atlassian Confluence
Sun Guidelines on Public Discourse Privacy Policy Terms of Use Trademarks Site Map Employment Investor Relations Contact