In this serious of documents I have been describing the entire start to finish process of install the software,deploying and configuring Access Manager and the necessary changes required to support CACAuthentication with Access Manager. This document assumes that you have an installed and working theGlassFish Enterprise Application Server and Sun Access Manager 7.1.Note: The GlassFish EnterpriseApplication Server is the renamed Sun Java Enterprise System Enterprise Application Server 9.1.

If your implementation involves the use of Access Manager Policy Agents it will be necessary to configurea second SSL listener without the Client Certificate “Required option” being set. The policy agent must beable to log into the Access Manager for it to function. Since the SSL listener configured in this documentrequires a certificate the policy agent willNOT

be allowed to communicate with AccessManager. I will bedeveloping another document later that will describe options to resolve this issue.

1.1

Assumptions

1.

In this document the example assumes that the server being installed issedemo1identric.com. Thisreference should be replaced with your specific server name.

2.

It is also assumed that the GlassFish Enterprise Application Server was installed in/opt/SUNWappserver

3.

This document assumes that Access Manager is already running and configured to use SSL.

2

Configuring CAC Authentication

In the following instructions it is assumed that the server that is being used issedemo1.identric.com.

2.1

Modify the AMConfig.properties file

1.

Login in as a super user to the Access Manager server.

2.

Make a backup of the AMConfig.properties file. Do this by:



cd /etc/opt/SUNWam



cp AMConfig.properties AMConfig.properties.bck

3.

The following two lines must be changed in order for Access Manager to locate the OCSP SigningCertificate and the OCSP server. Locate and modify the following 3 lines (the nickname attribute mustbe setto the name of the nickname used with the OCSP signing certificate is loaded into the certificatedatabase):

com.sun.identity.authentication.ocspCheck=true

com.sun.identity.authentication.ocsp.responder.url=

com.sun.identity.authentication.ocsp.responder.nickname=

to look like: (Note: the nickname must match the value used when the OCSP signing certificate wasloaded)

Before these changes take affect the Application Server must be restarted. If you are continuingthrough the configuration you can restart the application server after the changes to the ApplicationServer are completed.

2.2

Create the CAC Authentication Module and Chain

8.

Login to the Access Manager console at

https://sedemo1.identric.com/amserver/console

using the useramadmin

and the password configured during the installation.

9.

Create the CAC Authentication Module by clicking on theAccess ControlTab and then click on thehyperlink for the realm.

10.

Click on theAuthentication

Tab and then click on theNew

button underModule Instances.

11.

On the screen that is displayed specify the name of the module,CAC, and select certificate and thenclick on theOK

button:

12.

Select the hyperlink of the newly created Module Instance. Once the page is displayed the only thingthat must be change is theOCSP Validation

needs to be enabled. Once enabled click theSave

buttonand thenBack to Authentication:

13.

Create a new chain for the CAC Module. This is done by clicking on theNew

button underAuthentication Chaining.

14.

In the new window specify the NameCACChain

and then click theOK

button.

15.

On the next screen click theAdd

button and then select the moduleCAC

and mark it asRequired

andthen click theSave

button thenBack to Authentication.

16.

Next make the newly created chain the Default Authentication Chain by selectedCACChain

in theDefault Authentication Chain

and then clickSave:

17.

Finally click on theAdvanced Properties

button and changeUser Profile

toDyamic. Then click theSave

button:

18.

Restart the Web Server and when the web server restarts CAC Authentication should be enabled withOCSP verification. When a user authenticates with their CAC a new profile will be added to AccessManager

3

Configuring the Application Server

3.1

Modify the SSLListener

In order for the Application Server to request the certificate from the CAC card, the SSL Listener hostingAccess Manager must be configured to obtain the certificate. Use the application server admin console toconfigure the SSL Listener for “Client Certificate Required.” This is done by doing the following:

The OCSP server that is used to vet CAC cards required a signing signature. This signaturemust beloaded in the certificate database. Obtain this certificate from your source of certificates To load theOCSP signing certificate do the following:

a.

cd /opt/SUNWappserver/domains/domain1/config

b.

certutil

-A-n "DoDocspCertificate"-d .-i certificate.cer-t "CT,CT,CT"

2.

In order for the Application Server to request the necessary certificates from the CAC card the DoDCA PKI Root Certificates must be loaded into the certificate database. Obtain these appropriatecertificates from your security resource. You now should install the DoD CA-11, DoD CA-12, DoDCA-13, DoD CA-14, DoD CA-15, DoD CA-16, DoD CA-17, DoD CA-18 and DoD CA-19certificates. Do the following to load the certificates:

c.

/opt/SUNWappserver/domains/domain1/config

d.

certutil–A–n DoDCA_11–d

.–i DoDCA_11.crl–t “CT,CT,CT”

e.

repeat the above step for all of the necessary DoD CA Roots.

3.

The Application Server must be restarted:

/opt/SUNWappserver/bin/asadmin stop-domain

/opt/SUNWappserver/bin/asadmin start-domain–user admin domain1

4

Troubleshooting

The most difficult part of this configuration is getting the OCSP check to work properly. DISA requires asigning certificate be configured. This is described in the instructions above. For the OCSP check to workthe Access Manager server must be ableto access theocsp.disa.mil

server via port80.

4.1

Troubleshooting thought 1-

Using telnet

This can be tested by logging into the Access Manager server a type the following from the command line:

telnet ocsp.disa.mil 80

if the following occurs typeGET:

Trying 164.235.15.70...

(Note: maybe a different IP Address)

Connected to ocsp.csd.disa.mil.

Escape character is '^

The response to the GET should look something like:

HTTP/1.1 400 Bad Request

Cache-Control: no-cache

Pragma: no-cache

Content-Type: text/html; charset=utf-8

Proxy-Connection: close

Connection: close

Content-Length: 690

<HTML><HEAD>

<TITLE>Request Error</TITLE>

</HEAD>

<BODY>

<FONT face="Helvetica">

<big><strong></strong></big><BR>

</FONT>

<blockquote>

<TABLE border=0 cellPadding=1 width="80%">

<TR><TD>

<FONT face="Helvetica">

<big>Request Error (invalid_request)</big>

<BR>

<BR>

</FONT>

</TD></TR>

<TR><TD>

<FONT face="Helvetica">

Your request could not be processed.

</FONT>

</TD></TR>

<TR><TD>

<FONT face="Helvetica">

This could be caused by a misconfiguration, or possibly a malformed request.

If you see this type of response then you have a good connection to the OCSP server. If you do NOT seethis type of response you must determine why your network will not let you access this host and port.

4.2

Troubleshooting thought 2-

Using Open SSL

Another valuable tool for debugging the process is the use of the OpenSSL utility. To use this commandyou must have the DoD Root CA certificate for your CAC card (for example DoD-16), the OCSP signingcertificate and the user certificate from the CAC card being tested. Run the command as shown below: