Approving User Accounts

When a user is added to the Identity Manager system, administrators who are assigned as approvers for new accounts must validate account creation.

Identity Manager supports three categories of approval:

• Organization. Approval is needed for the user account to be added to the organization.

• Role. Approval is needed for the user account to be assigned to a role.

• Resource. Approval is needed for the user account to be given access to a resource.

In addition, if change-approvals are enabled, and changes are made to a role, a change-approval work item is sent to designated role owners.

Identity Manager supports change-approvals by Role Definition. If an administrator changes a role definition, change-approval is needed from a designated role owner. A role owner must approve the work item in order for the change to be made.

---

Note –

• You can configure Identity Manager for digitally signed approvals. For instructions see Configuring Digitally Signed Approvals and Actions.

• Administrators who are new to Identity Manager sometimes confuse the concept of approvals with the similar sounding concept of attestation. While the names sound similar, approvals and attestation take place in different contexts.

  Approvals are concerned with validating new user accounts. When a user is added to Identity Manager, one or more approvals may be required to validate that the new account is authorized.

  Attestations are concerned with verifying that existing users have only appropriate privileges on appropriate resources. As part of a Periodic Access Review process, an Identity Manager user (the attestor) may be called upon to certify that another user’s account details (that is, the user’s assigned resources) are valid and correct. This process is known as attestation.

---

Setting Up Account Approvers

Setting up account approvers for organization, role, and resource approvals is optional, but recommended. For each category in which approvers are set up, at least one approval is required for account creation. If one approver rejects a request for approval, the account is not created.

You can assign more than one approver to each category. Because only one approval within a category is needed, you can set up multiple approvers to help ensure workflow is not delayed or halted. If one approver is unavailable, others are available to handle requests. Approval applies only to account creation. By default, account updates and deletions do not require approval. You can, however, customize this process to require it.

You can customize workflows by using the Identity Manager IDE to change the flow of approvals, capture account deletions, and capture updates.

For information about the Identity Manager IDE, go to https://identitymanager.dev.java.net. For information about workflows, and an illustrated example of altering the approval workflow, see Chapter 2, Workflow, in Sun Identity Manager Deployment Reference.

Identity Manager Approvers can either approve or reject an approval request.

Administrators can view and manage pending approvals from the Work Items area of the Identity Manager interface. From the Work Items page, click My Work Items to view pending approvals. Click the Approvals tab to manage approvals.

Signing Approvals

To approve a work item using a digital signature, you must first set up the digital signature as described in Configuring Digitally Signed Approvals and Actions.

To Sign an Approval

1. From the Identity Manager Administrator interface, select Work Items.

2. Click the Approvals tab.

3. Select one or more approvals from the list.

4. Enter comments for the approval, and then click Approve.

   Identity Manager prompts you and asks whether to trust the applet.

5. Click Always.

   Identity Manager displays a dated summary of the approval.

6. Enter or click Browse to locate the keystore location. (This location is set during the signed-approval configuration, as described in Step 10m of the To Enable Server-Side Configuration for Signed Approvals Using PKCS12 procedure. )

7. Enter the keystore password (this password is set during the signed-approval configuration, as described in Step 10l of the procedure To Enable Server-Side Configuration for Signed Approvals Using PKCS12).

8. Click Sign to approve the request.

Signing Subsequent Approvals

After signing an approval, subsequent approval actions require only that you enter the keystore password and then click Sign. (Identity Manager remembers the keystore location from the previous approval.)

Configuring Digitally Signed Approvals and Actions

Use the following information and procedures to set up digital signing. You can digitally sign:

• Approvals (including change-approvals)

• Access review actions

• Remediations for compliance violations

The topics discussed in this section explain the server-side and client-side configuration required to add the certificate and CRL to Identity Manager for signed approvals.

To Enable Server-Side Configuration for Signed Approvals

1. Open the system configuration object for editing and set security.nonrepudiation.signedApprovals=true

   For instructions on editing the system configuration object, see Editing Identity Manager Configuration Objects.

   If you are using PKCS11 you must also set security.nonrepudiation.defaultKeystoreType=PKCS11

   If you are using a custom PKCS11 Key provider, you must also set security.nonrepudiation.defaultPKCS11KeyProvider=your provider name

   ---

   Note –

   Please refer to the following items in the REF kit for more information on when you need to need to write a custom provider:

   com.sun.idm.ui.web.applet.transactionsigner.DefaultPKCS11KeyProvider (Javadoc) REF/transactionsigner/SamplePKCS11KeyProvider

   The REF (Resource Extension Facility) kit is provided in the /REF directory on your product CD or with your install image.

   ---

2. Add your certificate authority's (CA) certificates as trusted certificates. To do this, you must first obtain a copy of the certificates.

   For example, if you are using a Microsoft CA, follow steps similar to these:

   1. Go to http://IPAddress/certsrv and log in with administrative privileges.

   2. Select Retrieve the CA certificate or certificate revocation list, and then click Next.

   3. Download and save the CA certificate.

3. Add the certificate to Identity Manager as a trusted certificate:

   1. From the Administrator interface, select Security, and then select Certificates. Identity Manager displays the Certificates page.

      Figure 6–6 Certificates Page

      
      

   2. In the Trusted CA Certificates area, click Add. Identity Manager displays the Import Certificate page.

   3. Browse to and then select the trusted certificate, and then click Import.

      The certificate now displays in the list of trusted certificates.

4. Add your CA’s certificate revocation list (CRL):

   1. In the CRLs area of the Certificates page, click Add.

   2. Enter the URL for the CA’s CRL.

      ---

      Note –

      • The certificate revocation list (CRL) is a list of certificate serial numbers that have been revoked or are not valid.

      • The URL for the CA’s CRL may be http or LDAP.

      • Each CA has a different URL where CRLs are distributed; you can determine this by browsing the CA certificate’s CRL Distribution Points extension.

      ---

5. Click Test Connection to verify the URL.

6. Click Save.

7. Sign applets/ts2.jar using jarsigner.

   ---

   Note –

   Refer to http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/jarsigner.html for more information. The ts2.jar file provided with Identity Manager is signed using a self-signed certificate, and should not be used for production systems. In production, this file should be re-signed using a code-signing certificate issued by your trusted CA.

   ---

To Enable Server-Side Configuration for Signed Approvals Using PKCS12

The following configuration information is for signed approvals using PKCS12. Obtain a certificate and private key, and then export them to a PKCS#12 keystore. For example, if using a Microsoft CA, you would follow steps similar to these:

Before You Begin

Identity Manager now requires at least JRE 1.5.

1. Using Internet Explorer, browse to http://IPAddress/certsrv and log in with administrative privileges.

2. Select Request a certificate, and then click Next.

3. Select Advanced request, and then click Next.

4. Click Next.

5. Select User for Certificate Template.

6. Select these options:

   1. Mark keys as exportable.

   2. Enable strong key protection.

   3. Use local machine store.

7. Click Submit, and then click OK.

8. Click Install this certificate.

9. Select Run -> mmc to launch mmc.

10. Add the Certificate snap-in:

    1. Select Console -> Add/Remove Snap-in.

    2. Click Add.

    3. Select Computer account.

    4. Click Next, and then click Finish.

    5. Click Close.

    6. Click OK.

    7. Go to Certificates -> Personal -> Certificates.

    8. Right-click Administrator All Tasks -> Export.

    9. Click Next.

    10. Click Next to confirm exporting the private key.

    11. Click Next.

    12. Provide a password, and then click Next.

    13. File CertificateLocation.

    14. Click Next, and then click Finish. Click OK to confirm.

        ---

        Note –

        Note the information that you use in step 10l (password) and 10m (certificate location) of the client-side configuration. You will need this information to sign approvals.

        ---

To Enable Client-Side Configuration for Signed Approvals Using PKCS11

If you are using PKCS11 for signed approvals

1. Refer to the following resources in the REF kit for configuration information:

   com.sun.idm.ui.web.applet.transactionsigner.DefaultPKCS11KeyProvider (Javadoc) REF/transactionsigner/SamplePKCS11KeyProvider

   The REF (Resource Extension Facility) kit is provided in the /REF directory on your product CD or with your install image.

Viewing the Transaction Signature

This section describes the procedure for viewing transaction signatures in an Identity Manager AuditLog report.

To View a Transaction Signature

1. From the Identity Manager Administrator interface, select Reports.

2. On the Run Reports page, select AuditLog Report from the New list of options.

3. In the Report Title field, enter a title (for example, Approvals).

4. In the Organizations selection area, select all organizations.

5. Select the Actions option, and then select Approve.

6. Click Save to save the report and return to the Run Reports page.

7. Click Run to run the Approvals report.

8. Click the details link to see transaction signature information.

   Transaction signature information can include the following:

   • Issuer

   • Subject

   • Certificate serial number

   • Message signed

   • Signature

   • Signature algorithm

Configuring XMLDSIG-Format Signed Approvals

Identity Manager allows you to add XMLDSIG-format signed approvals, including an RFC 3161-compliant digital timestamp, to the Identity Manager approval process. When you configure Identity Manager to use XMLDSIG signed approvals, no changes are visible to approvers unless they view the approval in the audit log. Only the format of the signed approval that is stored in the audit log record is changed.

As with previous signed approvals in Identity Manager, an applet is launched on the client machine and the approver is presented with the approval information for signing. They then choose a keystore and a key with which to sign the approval.

After the approver signs the approval, an XMLDSIG document containing the approval data is created. This document is returned to the server which validates the XMLDSIG signed document. If successful, and if RFC 3161 digital timestamps have been configured, a digital timestamp is also generated for this document. The timestamp retrieved from the timestamp authority (TSA) is checked for errors and its certificates are validated. Finally, if successful, Identity Manager generates an audit log record that includes the XMLDSIG-format signed approval object in the XML blob column.

Approval Data Format

The format for an XMLDSIG-format approval object is as follows:

<XMLSignedData signedContent="...base64 transaction text ...">
   <XMLSignature>
      <TSATimestamp>
         ...The base64 encoded PKCS7 timestamp token returned by the TSA...
      </TSATimestamp
      <Signature>
        <SignedInfo>...XMLDSIG stuff...</SignedInfo>
        <SignatureValue>...base64 signature value</SignatureValue>
        <KeyInfo>...cert info for signer</KeyInfo>
      </Signature>
   </XMLSignature>
</XMLSignedData>

where:

• The base64 approval data consists of the actual approval data text that is presented to the approver in the applet, encoded in base64 format.

• The <TSATimestamp> element contains the base64 encoded PKCS7 timestamp response from the Timestamp Authority (TSA).

• The entire <Signature> comprises the XMLDSIG signature data.

This XMLDSIG document that is stored in the XML column of the audit log approval record.

Installation and Setup

The installation and setup requirements for using XMLDSIG signed approvals are the same as those described in To Enable Server-Side Configuration for Signed Approvals, with one additional step. You must sign the xmlsec-1.4.2.jar file in addition to signing the ts2.jar file.

Approval Configuration

You can use system configuration attributes to:

• Choose the SignedData format or the XMLSignedData format. Note that you can configure only one format at a time, although administrators can change this setting as needed.

• Include a digital timestamp retrieved from a configured RFC 3161 Timestamp Authority (TSA).

• Specify a URL, in HTTP only, from which to fetch this timestamp.

To edit these attributes, use the Identity Manager debug pages to edit the system configuration object. These attributes are all located under security.nonrepudiation, along with other signed approval attributes.

The XMLDSIG attributes include:

• security.nonrepudiation.useXmlDigitalSignatures is a boolean value that enables XMLDSIG signatures.

• security.nonrepudiation.timestampXmlDigitalSignatures is a boolean value that includes RFC 3161 digital timestamps in XMLDSIG signatures.

• security.nonrepudiation.timestampServerURL is a string value where the URL points to the HTTP-based TSA from which to fetch timestamps.

---

Note –

• You must first set the existing useSignedApprovals attribute to true for any of the preceding attributes to have an effect.

• Identity Manager does not support multiple signatures on one approval or signed approvals for more general provisioning requests.

---