To configure basic cache settings:

1. Go to the Caching page.

2. In the Cache Configuration section of the page, specify global or local values for the following settings, as appropriate:

   Setting	What to do
   Lock Acquisition Timeout	Specify the time interval (in milliseconds) that the cache waits for a lock to be acquired on an object. You might want to increase this setting if the User Application gets a lot of lock timeout exceptions in the application log. The default is 15000 ms.
   Wake Up Interval Seconds	Specify the time interval (in seconds) that the cache eviction policy waits before waking up to do the following: Process the evicted node events Clean up the size limit and age-out nodes
   Eviction Policy Class	Specify the classname for the cache eviction policy that you want to use. The default is the LRU eviction policy that JBoss Cache provides: org.jboss.cache.eviction.LRUPolicy If appropriate, you can change this to another eviction policy that JBoss Cache supports.
   Max Nodes	Specify the maximum number of nodes allowed in the cache. For no limit, specify: 0 You can customize this setting for some cache holders. See Customizable Cache Holders.
   Time To Live Seconds	Specify the time to idle (in seconds) before the node is swept away. For no limit, specify: 0 You can customize this setting for some cache holders. See Customizable Cache Holders.
   Max Age	Specifies the number of seconds an entry should be allowed to stay in the cache holder since its creation time. For no time limit, specify: 0 This setting is only available for Customizable Cache Holders.

   These settings are required, which means that there must be a global value for each, and optionally a local value too.

   If you want to override the global value of a setting with a local value, select the Enable Local check box for that setting. Then specify the local value. (Make sure that all of your local values are valid. Otherwise, you won’t be able to save your changes.)

   NOTE:For those settings where Enable Local is deselected, any existing local values are deleted when you save.

3. Click Save.

4. When you’re ready for your saved settings to take effect, restart the User Application on the applicable application servers.

1. Set up your JGroups cluster. This involves using the User Application installation program to install the Identity Manager User Application to each application server in the cluster (see Section 2.8, Clustering).

2. Enable the use of that cluster in the User Application’s cache configuration settings

   See Configuring Cache Settings for Clusters.

1. Go to the Caching page.

2. In the Cluster Configuration section of the page, specify global or local values for the following settings, as appropriate:

   Setting	What to do
   Cluster Enabled	Select True to invalidate cache changes to the other nodes in the cluster specified by Group ID. If you don’t want to participate in a cluster, select False.
   Group ID	Specify the Group ID of the JGroups cluster in which you want to participate. There’s no need to change the default Group ID that’s provided for the User Application’s cluster, unless you want to use a different cluster. The Group ID must be unique and must not match any of the known JBoss cluster names such as DefaultPartition and Tomcat-Cluster. HINT:To see the Group ID in logging messages, make sure that the level of the caching log (com.sssw.fw.cachemgr) is set to Info or higher.
   Cluster Properties	Specify the JGroups protocol stack for the cluster specified by Group ID. This setting is for experienced administrators who might need to adjust the cluster properties. Otherwise, you should not change the default protocol stack. To see the current cluster properties, click view. For details on the JGroups protocol stack, go to www.jboss.org/wiki/Wiki.jsp?page=JGroups.

   If you want to override the global value of a setting with a local value, select the Enable Local check box for that setting. Then specify the local value.

   For those settings where Enable Local is unselected, any existing local values are deleted when you save.

   Make sure that all nodes in your cluster specify the same Group ID and Cluster Properties. To see these settings for a particular node, you must access the Identity Manager user interface running on that node—by browsing to the URL of the user interface on that server—and then display the Caching page there.

   If you need to use the TCP protocol instead of the default UDP protocol, see Specifying the User Application Cluster Group Caching Configuration.

3. Click Save.

4. When you’re ready for your saved settings to take effect, restart the User Application on the applicable application servers.

To install the SAML and NMAS authentication methods on eDirectory:

1. Unzip nmassaml.zip (in the /products/RBPM/SAML directory).

2. Install the SAML and NMAS methods into your eDirectory tree:

   1. Extend the schema stored in authsaml.sch. Refer to Post-Installation Tasks, in the Identity Manager Roles Based Provisioning Module 4.0.2 User Application: Installation Guide, for more information. If eDirectory is installed on Linux, you can use the following command to extend the schema:

      ndssch -h edir_ip edir_admin authsaml.sch 
      

   2. Install the methods. Refer to “How to Install NMAS Method” , in the Novell Modular Authentication Services Administration Guide, for more information. If eDirectory is installed on Linux, you can use the following command to install the methods:

      nmasinst -addmethod edir_admin tree ./config.txt 
      

To create the Trusted Root Container:

1. In iManager, select Roles and Tasks > Novell Certificate Server > Create Trusted Root Container.

2. Enter a Name for the Trusted Root Container (for example, RBPMTrustedRootContainer).

3. For the Context, press the Search button and select the Security Container.

4. Press OK.

5. Press OK.

To create a Trusted Root for the certificate that your affiliate will use to sign assertions:

1. In iManager, select Roles and Tasks > Novell Certificate Server > Create Trusted Root.

2. Enter a Name for the Trusted Root (for example, RBPMTrustedRoot).

3. For the Container, press the Search button and select the Trusted Root Container you created earlier.

4. For the Certificate File, press the Browse button and select the certificate that will be used for the SSO Controller.

5. Click Finish, then click Close.

To create the SAML Authorization Object:

1. In iManager, select Roles and Tasks > Directory Administration > Create Object.

2. Select the checkbox for Show all object classes.

3. Scroll down and select authsamlAffiliate.

4. Press OK.

5. Enter a Name for the authsamlAffiliate (for example, RBPMSAML).

6. For the Context, press the Search button and follow these steps:

   1. Select the down arrow next to Security.

   2. Select the down arrow next to Authorized Login Methods.

   3. Select SAML Assertion.

7. Press OK.

8. Press Modify.

9. Under Unvalued Attributes:

   1. Select authsamlProviderID and press the left arrow.

   2. Enter the following attribute:

      rbpm.idm.novell.com
      

      NOTE:This attribute is used to match an assertion with its affiliate. The contents of this attribute must be an exact match with the Issuer attribute in assertions sent by this affiliate. It must be rbpm.idm.novell.com for RBPM.

   3. Click OK.

   4. Select authsamlValidAfter and press the left arrow.

   5. Enter an appropriate amount of time in seconds. The authsamlValidBefore and authsamlValidAfter attributes define a window of time around the IssueInstant in an assertion in which the assertion will be considered valid.

   6. Click OK.

   7. Select authsamlValidBefore and press the left arrow.

   8. Enter an appropriate amount of time in seconds.

   9. Click OK.

   10. Select authsamlCertContainerDN and press the left arrow.

   11. Press the Browse button and select the Trusted Root Container created earlier. This attribute is used to verify the certificate chain of the signing certificate.

   12. Click OK.

   13. Select authsamlTrustedCertDN and press the left arrow.

   14. Press the Browse button and select the Trusted Root created earlier. This will be located inside of the Trusted Root Container that was created earlier. All assertions for the affiliate must be signed by certificates pointed to by this attribute, or they will be rejected.

   15. Click OK, then click OK again.

10. Press Apply.

11. Click OK.

12. Restart eDirectory.

To prepare the Key Distribution Center (KDC):

1. Prepare RBPM's Service Principal Name (SPN) and Keytab:

   1. Create a user account for RBPM in a Microsoft Active Directory.

      On the Microsoft Active Directory server, click Start>Programs>Administrative Tools>Active Directory Users and Computers. Then click Users>New, specifying any name, such as rbpm. Provide a password you will remember. This account should only be used for the Roles Based Provisioning Module.Select Account never expires and Password never expires. Do not select User must change password at next logon.

   2. Map the user account to SPN.

      setspn -A HTTP/dns-name-for-UA userID
      

      For example:

      setspn -A HTTP/myRBPM.novell.com rbpm 
      

      Type setspn -L userID to confirm the mapping. For example:

      setspn -L rbpm
      

   3. Create key tab for SPN.

      If Active Directory is installed on Windows 2008, execute this command:

      ktpass -out keytab-name.keytab -princ HTTP/dns-name-for-UA@WINDOWS-DOMAIN -mapUser userid -mapOp set -pass password -crypto All -pType KRB5_NT_PRINCIPAL 
      

      For example:

      ktpass -out rbpm.keytab -princ HTTP/rbpm.novell.com@MYDOMAIN.NOVELL.COM -mapUser rbpm -mapOp set -pass N0v3ll -crypto All -pType KRB5_NT_PRINCIPAL 
      

      NOTE:The encryption types and algorithms you can specify for Windows 2008 depend upon the domain functional level at which the domain is set, as well as domain-specific configurations.

      If Active Directory is installed on Windows 2003, execute this command:

      ktpass -out keytab-name.keytab -princ HTTP/dns-name-for-UA@WINDOWS-DOMAIN -mapUser userid -mapOp set -pass password -pType KRB5_NT_PRINCIPAL 
      

      For example:

      ktpass -out rbpm.keytab -princ HTTP/rbpm.novell.com@MYDOMAIN.NOVELL.COM -mapUser rbpm -mapOp set -pass N0v3ll -pType KRB5_NT_PRINCIPAL 
      

      Note that for Windows 2003, by not specifying a crypto algorithm, you are defaulting the algorithm to RC4-HMAC.

2. Prepare end user accounts for SSO.

   The end user account name has to match some attribute value of an eDirectory user in order to support single sign-on.

   Create an end user in Active Directory, as follows:

   1. On a Microsoft Active Directory server, click Start>Programs>Administrative Tools>Active Directory Users and Computers. Then click Users>New, specifying the user name, such as cnano. Provide a password you will remember.Do not select User must change password at next logon.

To prepare the Application Server environment:

1. Define the OS settings for the Kerberos configuration.

   Open and edit the krb5 file to include the following information:

   [libdefaults]
       default_realm = WINDOWS-DOMAIN
       kdc_timesync = 0
       forwardable = true
       proxiable = false
   [realms]
       WINDOWS-DOMAIN = {
           kdc = fully-qualified-name-AD-Server 
     admin_server = fully-qualified-name-AD-Server
       }
   [domain_realm]
       .your.domain = WINDOWS-DOMAIN
       your.domain = WINDOWS-DOMAIN
   

   For example:

   [libdefaults]
       default_realm = MYDOMAIN.NOVELL.COM
       kdc_timesync = 0
       forwardable = true
       proxiable = false
   [realms]
       MYDOMAIN.NOVELL.COM = {
           kdc = myadserver.cam.novell.com 
     admin_server = myadserver.cam.novell.com
       }
   [domain_realm]
       .novell.com = MYDOMAIN.NOVELL.COM
       novell.com = MYDOMAIN.NOVELL.COM
   

   The krb5 file is located in one of the following directories:

   • Linux: /etc/krb5.conf

   • Windows: c:\Windows\krb5.ini

   • Unix: /etc/krb5/krb5.conf

2. Define the Web Container settings (JBoss):

   1. Copy the keytab from Active Directory.

      Copy myRBPM.keytab from myadserver.cam.novell.com to myRBPM.

   2. Edit login-config.xml.

      Open and add the following fragment to jboss/server/context/conf/login-config.xml:

      <application-policy name = "com.sun.security.jgss.krb5.accept">
            <authentication>
                <login-module code = "com.novell.common.auth.sso.KerberosCredentialLoginModule" flag = "required" />
                <login-module code = "com.sun.security.auth.module.Krb5LoginModule" flag = "required">
                    <module-option name = "debug">false</module-option>
                    <module-option name = "kdc">fully-qualified-name-AD-Server</module-option>
                    <module-option name = "realm">WINDOWS-DOMAIN</module-option>
                    <module-option name = "useKeyTab">true</module-option>
                    <module-option name = "keyTab">path-to-keytab</module-option>
                    <module-option name = "storeKey">true</module-option>
                    <module-option name = "useFirstPass">true</module-option>
                    <module-option name = "principal">HTTP/dns-name-for-UA</module-option>
                    <module-option name = "noPrompt">true</module-option>
                </login-module>
            </authentication>
        </application-policy>
      

      For example:

      <application-policy name = "com.sun.security.jgss.krb5.accept">
            <authentication>
                <login-module code = "com.novell.common.auth.sso.KerberosCredentialLoginModule" flag = "required" />
                <login-module code = "com.sun.security.auth.module.Krb5LoginModule" flag = "required">
                    <module-option name = "debug">false</module-option>
                    <module-option name = "kdc">myadserver.cam.novell.com</module-option>
                    <module-option name = "realm">MYDOMAIN.NOVELL.COM</module-option>
                    <module-option name = "useKeyTab">true</module-option>
                    <module-option name = "keyTab">/home/userapp/IDM370/rbpm.keytab</module-option>
                    <module-option name = "storeKey">true</module-option>
                    <module-option name = "useFirstPass">true</module-option>
                    <module-option name = "principal">HTTP/rbpm.novell.com</module-option>
                    <module-option name = "noPrompt">true</module-option>
                </login-module>
            </authentication>
        </application-policy>
      

      For WebSphere and WebLogic, a configuration file must be created and a property needs to be set to make the Application Server aware that Kerberos authentication will be used.

      Sample Kerberos_login.config for WebSphere Create a Kerberos_login.config file on the WebSphere Application server with the following content:

      IBMJGSSRBPM {com.ibm.security.auth.module.Krb5LoginModule required debug=true
      credsType=acceptor useKeytab=file:///c:/rbpm.keytab
      tryFirstPass=true principal="HTTP/rbpm.novell.com@MYDOMAIN.NOVELL.COM";};
      

      On Windows, use the file as is (remember to provide the exact location of the keytab file).

      On Linux, provide the absolute path of the keytab file. For example: /home/user/rbpm.keytab

      An entry needs to be added similar to the following in the Generic JVM arguments for Websphere.

      -Djava.security.auth.login.config=C:/kerberos_login.config
      

      Sample Kerberos_login.conf for WebLogic Create a Kerberos_login.conf file on the WebLogic Application server with the following content:

      com.sun.security.jgss.krb5.accept {
           com.sun.security.auth.module.Krb5LoginModule required
           principal="HTTP/rbpm.novell.com@MYDOMAIN.NOVELL.COM" useKeyTab=true
           keyTab="C:/rbpm.keytab" realm=MYDOMAIN.NOVELL.COM debug=true
      kdc=myadserver.cam.novell.com
           storeKey=true;};
      

      On Windows, use this file as is (remember to provide the exact location of the keytab file).

      On Linux, provide the absolute path of the keytab file. For example: /home/user/rbpm.keytab

      An entry needs to be added similar to the following in the JAVA_OPTS section of setDomainEnv.sh (on Linux) and setDomainEnv.cmd (on Windows):

      -Djava.security.auth.login.config=C:/kerberos_login.conf
      

3. Enable the Kerberos SSO Provider, as described in Using the Administration Tab to Configure the Kerberos Provider.

To prepare the end user browser (Internet Explorer 7):

1. Open Internet Explorer > Options > Advanced, make sure integrated windows authentication is enabled.

2. Open Internet Explorer > Options > Intranet > Sites, add the dns-name-for-UA (for example, rbpm.novell.com) to the trusted intranet sites list.

To prepare the end user browser (Firefox 3):

1. Type about:config in the address bar.

2. Type network.n in the Filter.

3. Modify network.negotiate-auth.trusted-uris to include your domain (for example, .novell.com).

4. Close and restart Firefox.

To prepare the Key Distribution Center (KDC):

1. Install and configure the MIT KDC software.

   Install MIT Kerberos 5 server on a machine that will be used as the KDC, assuming the Kerberos domain is MYDOMAIN.NOVELL.COM and the KDC is myadserver.cam.novell.com.

   NOTE:SLES 11 comes with a pre-installed version of MIT Kerberos V5. You can configure it through yast2. Default Domain, Default Realm, and KDC Server Address for basic setup. You'll need to configure the Kerberos Server for the KDC, and the Kerberos client for the client side. After you've enabled these, you still need to follow the steps below. However, this will save you time by removing the need to download and install Kerberos in your environment.

   1. In /etc/krb5.conf, make sure you define the domain and mapping correctly:

      [libdefaults]
              default_realm = MYDOMAIN.NOVELL.COM
      [realms]
              MYDOMAIN.NOVELL.COM = {
                      kdc = myadserver.cam.novell.com
                      admin_server = myadserver.cam.novell.com
              }
      [domain_realm]
              .novell.com = MYDOMAIN.NOVELL.COM
              novell.com = MYDOMAIN.NOVELL.COM
      

   2. In /usr/local/var/krb5kdc/kdc.conf (or /var/lib/kerberos/krb5kdc/kdc.conf, depending on your OS), make sure you specified the following entries with reasonable values:

      max_life = 8h 0m 0s
      max_renewable_life = 1d 0h 0m 0s
      

   3. Initialize the database:

      kdb5_util create -s
      

   4. Start KDC and Kadmin:

      /etc/init.d/krb5kdc start
      /etc/init.d/kadmind start
      

2. Prepare the RBPM Service Principal Name and Keytab.

   1. Create a principal for RBPM on MIT KDC.

      Suppose the User Application will be running on rbpm.novell.com. On the MIT KDC machine, execute the following command to create the service principal and assign it a random key.

      kadmin.local
      >ank -randkey HTTP/rbpm.novell.com
      

   2. Export the key into a keytab.

      ktadd -k /tmp/userapp.keytab HTTP/rbpm.novell.com
      

3. Prepare end user accounts for SSO.

   The end user name should be able to map to an eDirectory user (for example, cnano):

   kadmin.local
   >ank cnano
   

To prepare the Application Server environment:

1. Define the OS settings for the Kerberos configuration.

   Open and edit /etc/krb5.conf to make sure it has the same content as the one on the KDC (see above).

2. Define the Web Container settings (JBoss):

   1. Copy the keytab from KDC.

      Copy rbpm.keytab from the KDC (for example, myadserver.cam.novell.com) /tmp to the User Application server, securely.

   2. Edit login-config.xml.

      Open and add the following fragment to JBoss/server/context/conf/login-config.xml:

      <application-policy name = "com.sun.security.jgss.krb5.accept">
            <authentication>
                <login-module code = "com.novell.common.auth.sso.KerberosCredentialLoginModule" flag = "required" />
                <login-module code = "com.sun.security.auth.module.Krb5LoginModule" flag = "required">
                    <module-option name = "debug">false</module-option>
                    <module-option name = "kdc">fully-qualified-name-AD-Server</module-option>
                    <module-option name = "realm">WINDOWS-DOMAIN</module-option>
                    <module-option name = "useKeyTab">true</module-option>
                    <module-option name = "keyTab">path-to-keytab</module-option>
                    <module-option name = "storeKey">true</module-option>
                    <module-option name = "useFirstPass">true</module-option>
                    <module-option name = "principal">HTTP/dns-name-for-UA</module-option>
                    <module-option name = "noPrompt">true</module-option>
                </login-module>
            </authentication>
        </application-policy>
      

      For example:

      <application-policy name = "com.sun.security.jgss.krb5.accept">
            <authentication>
                <login-module code = "com.novell.common.auth.sso.KerberosCredentialLoginModule" flag = "required" />
                <login-module code = "com.sun.security.auth.module.Krb5LoginModule" flag = "required">
                    <module-option name = "debug">false</module-option>
                    <module-option name = "kdc">myadserver.cam.novell.com</module-option>
                    <module-option name = "realm">MYDOMAIN.NOVELL.COM</module-option>
                    <module-option name = "useKeyTab">true</module-option>
                    <module-option name = "keyTab">/home/userapp/IDM370/rbpm.keytab</module-option>
                    <module-option name = "storeKey">true</module-option>
                    <module-option name = "useFirstPass">true</module-option>
                    <module-option name = "principal">HTTP/rbpm.novell.com</module-option>
                    <module-option name = "noPrompt">true</module-option>
                </login-module>
            </authentication>
        </application-policy>
      

      NOTE:For WebSphere and WebLogic, a configuration file must be created and a property needs to be set to make the Application Server aware that Kerberos authentication will be used.

3. Enable the Kerberos SSO Provider, as described in Using the Administration Tab to Configure the Kerberos Provider.

To prepare the end user browser (Internet Explorer 7):

1. Initialize the ticket.

   Make sure you have same content in /etc/krb5.conf as in the KDC (see above). If your local login is "cnano", do kinit.

   Otherwise, do kinit cnano.

2. Prepare Firefox (Firefox 3):

   1. Type about:config in the address bar.

   2. Type network.n in Filter.

   3. Modify network.negotiate-auth.trusted-uris to include .novell.com.

   4. Close and restart Firefox.

To configure the Kerberos provider in the Administration tab of the User Application:

1. Select the Kerberos provider name and click Edit.

   The Kerberos dialog displays.

   

2. In the Expiration Interval field, specify the number of seconds that the SSO Header will be kept alive before expiring. This value defines the lifecycle of the SSO Header from the time it is issued. The expiration interval is needed to prevent replay attacks. You need to consider the network latency between your SSO Provider and the SSO Controller, as well as clock synchronization between the two components, if they are deployed on different machines.

3. In the User ID Mapping field, indicate whether the user ID will be associated with a user DN or with a user attribute, such as a CN. The User ID Mapping maps the user ID in the original realm to the eDirectory realm. If Distinguished Name is selected, the SSO UserID that appears in the SSO header has to be the full DN recognized by eDirectory. The SSO Controller will not try to do any user mapping. If User Attribute is selected, the SSO Controller will try to map the user from UserID to a full user DN. For a particular mapping, if the result is not unique (in other words, a single UserID maps to multiple users in eDirectory), or the result is none, the SSO Controller will refuse the SSO header, and the single sign-on operation will fail.

4. Browse to the Signing Certificate file you created earlier (for example, rbpm.cert) and upload it to the User Application.

   This file can be the same one used for the SSO Controller, or it can be generated separately for the Kerberos provider. To make your environment more secure, you should use a different certificate than the one used for the SSO Controller.

5. Browse to the Signing Key file you created earlier (for example, rbpm.pkcs8) and upload it to the User Application.

   This file can be the same one used for the SSO Controller, or it can be generated separately for the Kerberos provider. To make your environment more secure, you should use a different key than the one used for the SSO Controller.

6. In the Server protected by field, specify how the server will be protected by selecting Key or Password.

   The recommended approach is Key.

7. Click Save.

8. Select the checkbox next to Kerberos, and select Enable.

9. Restart the Application Server.

To test the single sign-on feature with Kerberos:

1. Login to the Windows Client Machine (on XP or Vista).

2. Open a browser and access the User Application by using a URL of this format:

   http://dns-name-for-UA:port/context/Kerberos
   

   For example:

   http://rbpm.novell.com:8080/IDMProv/Kerberos
   

3. If all of the components have been configured properly, you should see your default page in the User Application.

To configure the domains:

1. Make sure the User Application is in the same domain as the SAP portal. Single sign-on with the SAP logon ticket only works when both are in the same domain.

To configure the SAP logon ticket properties:

1. Follow the instructions on configuring SAP logon provided at Configuring Authentication and Single Sign-On.

   The steps below provide a simple example for the NW7 environment:

   1. Login to the SAP portal NWA (management) as administrator/passw0rd:

      http://w2k3entnw7.novell.com:50000/webdynpro/dispatcher/sap.com/tc~lm~webadmin~mainframe~wd/WebAdminApp
      

   2. Switch from the overview to the configuration tab. Choose system properties. Expand NW7 in right hand pane and choose global server configuration. Switch from Kernel to Services in Details section.

   3. Page down to row 31 and choose com.sap.security.core.ume.service. The Expanded Details section shows up at the bottom.

   4. Enable Filter on and type login. You should understand most of the settings and be able to verify that they are appropriate. Note that the login.ticket_lifetime is using minute as the time unit. This number must be very large.

   5. Now change the filter to logon. Note the item called ume.logon.security.relax_domain.level. It defines the domain level in which the ticket will take effect. For example, if the portal server is A.B.C.com and you set the domain level to 1, then any website under B.C.com will be able to single sign-on. If you set the domain level to 2, then any website under C.com will be able to single sign-on. This is achieved by the Set-Cookie's domain attribute.

To create a user in the SAP portal:

1. Login to the SAP portal as an administrator.

   To be able to single sign-on to the User Application, you must create a portal user who also has an account in eDirectory.

To configure SSO on the User Application:

1. Create the private keys and certificates, if you have not already done so. For details, see Creating the Certificates.

2. Enable the SSO Controller, if you have not already done so. For details, see Configuring the SSO Controller.

3. Enable the SAP SSO Provider, as described in Using the Administration Tab to Configure the SAP Provider.

   When you enable the SAP provider, you need to provide the SAP native library path and SAP ticket signing certificate path. You can download the native libraries through your SAP support channel. On the downloads page, select support packages and patches, and then choose applications by index. The name of the package is SAPSSOEXT. You will need to unzip the .SAR file by using SAPCAR utility.

   You can download the certificate from:

   http://w2k3entnw7.novell.com:50000/irj/portal --> system admin --> system configuration --> keystore administration --> download verify.pse 
   

1. Select the SAP provider name and click Edit.

   The SAP dialog displays.

   

2. In the Expiration Interval field, specify the number of seconds that the SSO Header will be kept alive before expiring. This value defines the lifecycle of the SSO Header from the time it is issued. The expiration interval is needed to prevent replay attacks. You need to consider the network latency between your SSO Provider and the SSO Controller, as well as clock synchronization between the two components, if they are deployed on different machines.

3. In the User ID Mapping field, indicate whether the user ID will be associated with a user DN or with a user attribute, such as a CN. The User ID Mapping maps the user ID in the original realm to the eDirectory realm. If Distinguished Name is selected, the SSO UserID that appears in the SSO header has to be the full DN recognized by eDirectory. The SSO Controller will not try to do any user mapping. If User Attribute is selected, the SSO Controller will try to map the user from UserID to a full user DN. For a particular mapping, if the result is not unique (in other words, a single UserID maps to multiple users in eDirectory), or the result is none, the SSO Controller will refuse the SSO header, and the single sign-on operation will fail.

4. Browse to the Signing Certificate file you created earlier and upload it to the User Application.

   This file can be the same one used for the SSO controller, or it can be generated separately for the SAP provider. To make your environment more secure, you should use a different certificate than the one used for the SSO controller.

5. Browse to the Signing Key file you created earlier and upload it to the User Application.

   This file can be the same one used for the SSO controller, or it can be generated separately for the SAP provider. To make your environment more secure, you should use a different key than the one used for the SSO controller.

6. Specify the path to the SAP Certificate File.

7. Specify the SAP Library Path.

8. Click Save.

9. Select the checkbox next to SAP, and select Enable.

10. Restart the Application Server.

To perform single sign-on with SAP:

1. Login to the SAP portal as an SAP user.

   NOTE:After logging in, you may see a message indicating that no portal roles have been assigned. This is because no portal permissions have been set up for this user. This is not a problem for single sign-on. As long as you see Log off link under the warning, you are logged in.

2. Access your User Application.

To logout:

1. Logoff from the SAP portal.

2. Logoff from the User Application.

   NOTE: If you don't logoff from the SAP portal, you won't be able to logout of the User Application. There is no mechanism to notify SAP that a user wants to logoff globally. Therefore, the ticket will keep you logged in.

To configure a custom provider in the Single Sign On page within the User Application:

1. Select the New button in the menu on the Single Sign On (SSO) page.

   The New SSO Provider dialog displays.

   

2. In the SSO Provider Name field, specify a name for the provider. This name must match the SSO Header Name, as described in Implementing and Deploying a Custom SSO Provider.

3. In the Expiration Interval field, specify the number of seconds that the SSO Header will be kept alive before expiring. This value defines the lifecycle of the SSO Header from the time it is issued. The expiration interval is needed to prevent replay attacks. You need to consider the network latency between your SSO Provider and the SSO Controller, as well as clock synchronization between the two components, if they are deployed on different machines.

4. In the User ID Mapping field, indicate whether the user ID will be associated with a user DN or with a user attribute, such as a CN. The User ID Mapping maps the user ID in the original realm to the eDirectory realm. If Distinguished Name is selected, the SSO UserID that appears in the SSO header has to be the full DN recognized by eDirectory. The SSO Controller will not try to do any user mapping. If User Attribute is selected, the SSO Controller will try to map the user from UserID to a full user DN. For a particular mapping, if the result is not unique (in other words, a single UserID maps to multiple users in eDirectory), or the result is none, the SSO Controller will refuse the SSO header, and the single sign-on operation will fail.

5. Browse to the Signing Certificate file you created earlier and upload it to the User Application.

   The file you use must be match the certificate of the private key used for the Signature, as described in Implementing and Deploying a Custom SSO Provider.

6. Click Save.

7. Select the checkbox next to the new custom provider, and select Enable.

8. Restart the Application Server.

1. Back up the deployed User Application WAR file (IDMProv.WAR) to the directory in which you install, for example the /opt/novell/idm subdirectory.

2. In a test environment, extract the contents of the User Application WAR file.

   The files that comprise the User Application’s themes are located in the resource\themes subdirectory. Each theme resides in its own directory with an appropriate name.

3. In the test environment, create a directory for the custom theme.

   The directory name can be any valid directory name, but it should reflect the name of the theme, and it should not contain spaces.

4. Copy the contents of the BlueGloss theme from the extracted WAR file to the new subdirectory. You will be working with the following files:

   File Name	Description
   theme.xml	The theme descriptor file. It includes entries for display name and description. They are used in the Themes page of the Administration tab. The remaining entries correspond to the brandable selectors. The width and height attributes on these entries are used in the branding page to reference the exact dimensions needed when a user uploads a customized version of these images. These entries must match their respective images, width and height as found in the themes.css.
   theme.css	Contains the CSS selectors used to style the look and feel of the user interface.
   print.css	Contains the CSS selectors used to style a print friendly version of the user interface.
   dojo.css	Contains a pointer to additional CSS files used by RBPM.
   An images subdirectory	Contains the images used by the theme.

   Rules for working with these files:

   • Do not change the names of the theme.xml, theme.css, print.css and dojo.css files.

   • The CSS Selector names must remain the same, but you can change the properties of the selectors to establish the look and feel.

   • The images subdirectory can have any name, but you must reference it correctly in the CSS and XML files.

5. Make your changes to the images, CSS style sheets and other theme elements as needed. The following changes are recommended:

   • In the theme.xml file:

     • display-name: Change this to a value that represents your theme. It displays as the Theme-name in the Themes page of the User Application’s Administration tab.

     • description: Change this to a value that describes your theme. It displays as the Description in the Themes page of the User Application’s Administration tab.

     • Consider whether to localize the display-name and Description fields.

     • Remove the following:

       <resource-bundle>com.novell.afw.portal.artifacts.theme.BlueGloss</resource-bundle>
       <resource-group>admin-resgrp</resource-group>
       

     • In the dojo.css file, change the @import line to the following value:

       @import url("../../../../IDMProv/javascript/dijit/themes/idmua/idmua.css");
       

       where IDMProv is the name of your WAR context.

     • If you wish to change the appearance of some Dojo elements, such as the menu buttons within the profile section on the Work Dashboard, you should take the following steps, instead of performing the steps above:

       1. Copy the following from your extracted WAR in this location: /javascript/dijit/themes:

          dijit.css
          dijit_rtl.css
          idmua (folder)
          

          Paste these items into your new theme folder.

       2. Change the @import line in the dojo.css file, as follows:

          @import url("idmua/idmua.css");
          

   • In the graphics directory:

     • thumbnails.gif: Replace the copy with your own image. This image displays along with the Theme-name and Description of the theme (described above) that is shown in the Themes page of the Administration tab. It typically illustrates what the User Application landing page looks like when the associated theme is applied

     • Renaming graphics files: If you change the names of graphics files (rather than just substituting a different image of the same name), make sure to change the reference to the image in both the theme.xml and the theme.css file. If the image is not used in the branding interface (for example, if it is not listed as one of the subset of brandable images in the theme.xml file), then you will only need to change the reference to the image in the theme.css file. Suppose you want to rename images/header_left.gif to images/my_company_name.gif. Edit the theme.css file to reflect the new image name.

6. After you make all of the desired changes to the theme files, add your customized theme directory to a new WAR file that contains one or more custom themes. Deploy the new WAR to your test application server. Testing tip: Open the Themes page (available under the Administration tab). Your theme should display along with the prepackaged themes. Use the Theme Preview action to see how the customized changes to your new theme will render. This is a useful way to preview many of your intended changes to your theme. Running through commonly used features of the application is also a recommended testing step.

7. After your changes are fully tested, you can deploy the WAR containing the custom theme to your production application server.