3 easy Steps to deploy dist auth on AM 7.1

Step-1: Deploy amauthdistui.war that you get with installation or by building it.

Step-2: Copy AMConfig.properties to WEB-INF/classes of web-app directory. File is pasted below. Change it depending upon environment

Step-3: Copy amclientsdk.jar to WEB-INF/lib of web-app directory.

Restart container.

--- Working AMConfig.properties file from my setup ---

/* The following keys are used to configure the Debug service.
* Possible values for the key 'level' are: off | error | warning | message.
* The key 'directory' specifies the output directory where the debug files
* will be created.
* Trailing spaces are significant.
* Windows: Use forward slashes "/" separate directories, not backslash "\".
* Windows: Spaces in the file name are allowed for Windows.
*/
com.iplanet.services.debug.level=error
com.iplanet.services.debug.directory=/var/opt/SUNWam/distauth/debug

/*
* Naming URL
*/
com.iplanet.am.naming.url=http://avatar.red.iplanet.com:80/amserver/namingservice

/*
* Notification URL
*/
com.iplanet.am.notification.url=

/*
* Security Credentials to identify the client to AccessManager and
* used to get the configuration data from AccessManager.
* com.sun.identity.agents.app.username is the name to identitfy
* the application.
* It is recommended that you create an agent identity to identify
* each client in the Access Manager.
* Then, use the agent identity corresponding to the client.
* This would provide better security and provide a better audit trail.
* The default for com.sun.identity.agents.app.username in this file may be
* set as "anonymous" only for ease of use.
*
* com.iplanet.am.service.password is the password corresponding to
* com.sun.identity.agents.app.username.
* Please remember to change this password when you change the value for
* com.sun.identity.agents.app.username
*/
com.sun.identity.agents.app.username=distauth
com.iplanet.am.service.password=password

/*
* Property to set JCE as the default encryption classes
*/
com.iplanet.security.encryptor=com.iplanet.services.util.JCEEncryption

/*
* Cache update time (in minutes) for user management cache,
* if notification URL is not provided
*/
com.iplanet.am.sdk.remote.pollingTime=1

/*
* Cache update time (in minutes) for service configutation data,
* if notification URL is not provided
*/
com.sun.identity.sm.cacheTime=1

/*
* Server protocol, host and port
*/
com.iplanet.am.server.protocol=http
com.iplanet.am.server.host=avatar.red.iplanet.com
com.iplanet.am.server.port=80

/*
* Distributed Authentication Server protocol, host and port
*/
com.iplanet.distAuth.server.protocol=http
com.iplanet.distAuth.server.host=jackal.red.iplanet.com
com.iplanet.distAuth.server.port=7070

com.iplanet.am.cookie.name=iPlanetDirectoryPro
com.iplanet.am.cookie.secure=false
com.iplanet.am.cookie.encode=false

/*
* Distributed Authentication Server deploy URI
*/
com.iplanet.am.services.deploymentDescriptor=/amauthdistui
com.iplanet.am.version=7.1

/*
* Distributed Authentication deploy URI
*/
com.iplanet.am.distauth.deploymentDescriptor=/amauthdistui

/*
* List of comma separated trusted Distributed Authentication servers in cluster
*/
com.sun.identity.distauth.cluster=

/*
* Identify cert db directory path, prefix and password file
* to initialize JSS Socket Factory when Web Container is configured SSL
*/
com.iplanet.am.admin.cli.certdb.dir=CONTAINER_CERTDB_DIR
com.iplanet.am.admin.cli.certdb.prefix=CONTAINER_CERTDB_PREFIX
com.iplanet.am.admin.cli.certdb.passfile=CONFIG_DIR/.wtpass

/*
* Since the notification handler is not registered on Distributed
* authentication side, the following polling parameters need to be specified
* to enable the SessionPoller thread.
*/
com.iplanet.am.session.client.polling.enable=true
com.iplanet.am.session.client.polling.period=180

/*
* Load Balancer cookie name and value to be used when there are multiple
* Distributed authentication web application servers behind Load Balancer.
*/
#com.iplanet.am.lbcookie.name=DistAuthLBCookieName
#com.iplanet.am.lbcookie.value=DistAuthLBCookieValue

com.sun.identity.auth.cookieName=AMDistAuthCookie

Steps to configure a CDSSO sample in OpenSSO

Deployment example:
------------------
OpenSSO updat1 patch 3 server on machine avatar.red.iplanet.com
Glassfish 3.0 J2EE Policy Agent on machine rub-s10-6.sfbay.sun.com


Step-1: Install OpenSSO server. Configure agent profile, policies.

Step-2: Install J2EE Policy Agent 3.0

Step-3: In container hosting agent, deploy mini agent sample application from http://developers.sun.com/identity/reference/techart/policyagents/agent-mini-app.zip

Step-4: In container hosting agent, deploy agentapp.war This is not installed by default. It is available in the following location:
/opt/lakshman/installations/agents/j2ee_agents/appserver_v9_agent/etc

Step-5: Configure agent profile for 3 properties mentioned in the link:
http://docs.sun.com/app/docs/doc/820-5816/aeabl?a=view
In my sample, the values are (Agent Profile -> SSO tab):
a) Enabled "Cross Domain SSO" checkbox
b) CDSSO Servlet URL: http://avatar.red.iplanet.com:8080/opensso/cdcservlet
c) CDSSO Domain List: .sun.com

Step-6: Set property "CDSSO Clock Skew" if you have not synchronized time between two machines hosting OpenSSO and agent.

Step-7: Add agent machine domain name to Realm/DNS Aliases

Step-8: Restart both containers hosting OpenSSO and glassfish server.

Trouble shooting tips:
----------------------
1. Do not add /agentapp/sunwCDSSORedirectURI to not-enforced-list. This has been discussed some places in a google search.

*************
Related docs:
*************
CDSSO Config
CDSSO Block Diagram
Mini agent sample deployment

Basic deployment test case for OpenSSO - Windows Desktop SSO Feature with Active Directory Domain Controller

This example uses:
Active Directory on Windows Server 2003 Standard Edition Service Pack 2
AD Domain name : SUST.IDM.COM
Windows Server machine name: parrot
IE Version : 7.0.5730.13
OpenSSO update-1 Patch-2
OpenSSO host name : avatar.red.iplanet.com

*****************************************************
Step-1: Active Directory Configuration:
*****************************************************
1. Login as administrator to the Windows Server.

2. Open "Manage Your Server" wizard
(Start Menu -> Administrative tools -> Manager Your Server)

3. Choose "Add or remove a role" option

4. Navigate to next screen "Configure Your Server Wizard".
(In the navigation process, if you run into any network connection warnings,
click continue and go ahead")

5. Choose "Domain Controller (Active Directory)" option

6. In the new wizard that pops up, choose default values.

7. Continue navigating. When you get a screen to enter Domain name, enter
SUST.IDM.COM - all capital letters. NetBIOS name as SUST (default value).

8. Navigate till you get an error for DNS.
Accept "Install and configure DNS on this server" option.

9. Complete installation process, restart the machine.

10. Login to the new domain just created SUST as Administrator

*****************************************************
Step-2: Create user account for OpenSSO server in AD
*****************************************************
1. Open "Manage Your Server" wizard.

2. Choose "Manage users and computers in Active Directory" option under Domain Controller role.

3. Go to "Users" menu under SUST.IDM.COM domain

4. Create a new user object with first name, last name, full name, logon name as: avatar
This is the name of the opensso host name so that you can easily remember.The default
password policy in Windows enforces atleast one capital letter and atleast one number. So
choose Password123 for simplicity.
NOTE: Do not have spaces in "Full Name" or logon name.
Else you will get DnsCrack error in the next configuration steps.

5. Open command prompt

6. CD to the directory where you want to have keytab file.

7. Run the following ktpass command:
C:\userData\lakshman>ktpass /princ HTTP/avatar.red.iplanet.com@SUST.IDM.COM /pass Password123 +DesOnly /crypto DES-CBC-CRC /ptype KRB5_NT_PRINCIPAL /mapuser avatar /out avatar.HTTP.keytab

Expected output in command prompt:
Targeting domain controller: parrot.SUST.IDM.COM
Successfully mapped HTTP/avatar.red.iplanet.com to avatar.
Key created.
Output keytab to avatar.HTTP.keytab:
Keytab version: 0x502
keysize 67 HTTP/avatar.red.iplanet.com@SUST.IDM.COM ptype 1 (KRB5_NT_PRINCIPAL)
vno 3 etype 0x1 (DES-CBC-CRC) keylength 8 (0x98628cd615045bc8)
Account avatar has been set for DES-only encryption.

8. ftp (in binary format) this keytab (avatar.HTTP.keytab) file to OpenSSO machine. In this example, ftp to the machine avatar.red.iplanet.com to the directory: /work/installations/opensso/patch/ad/

*****************************************************
Step-3: Validate keytab file on OpenSSO host name
*****************************************************

Command-1:
bash-3.00# klist -ek -t avatar.HTTP.keytab

Expected output in bash shell is:

Keytab name: FILE:avatar.HTTP.keytab
KVNO Timestamp Principal
---- ----------------- ---------------------------------------------------------
3 12/31/69 16:00:00 HTTP/avatar.red.iplanet.com@SUST.IDM.COM (DES cbc mode with CRC-32)


Command-2:
In "Active Directory Users and Computer" wizard on Windows Server 2003 machine, open user profile for avatar. Click on Account sub tab. Check that the value of field "User logon name as:
HTTP/avatar.red.iplanet.com

********************************************************
Step-4: Configure windows desktop SSO module in OpenSSO
********************************************************
1. Create a new authentication module - winsso. The parameters are:

Service Principal: HTTP/avatar.red.iplanet.com@SUST.IDM.COM

Keytab File Name: /work/installations/opensso/patch/ad/avatar.HTTP.keytab

Kerberos Realm: SUST.IDM.COM

Kerberos Server Name: parrot.red.iplanet.com

Return Principal with Domain Name: Disable check box

Authentication Level: 0

********************************************************
Step-6: Create Administrator profile in OpenSSO
********************************************************
1. Create a profile for Administrator in OpenSSO under Realm -> Subjects
For simplicity fill all name fields as Administrator and a password of your choice.

********************************************************
Step-7: Synchronize time & Restart
********************************************************
1. Synchronize time on both Windows Server 2003 machine and OpenSSO host name.
Seconds difference is acceptable in the synch process.

2. Restart container hosting OpenSSO war application - I mean OpenSSO server.

********************************************************
Step-8: Configure browser on Windows Server 2003 machine
********************************************************
1. This test scenario will use browser on Windows Server 2003 Domain Controller to test Windows Desktop SSO feature.

2. IE Browser (above 6.0 version):
a. Go to: Tools Menu -> Internet Options -> Security
b. Choose Local Intranet.
c. Click on Sites
d. Add OpenSSO machine name URL to the list. In this example
http://avatar.red.iplanet.com

3. Mozilla Firefox:
a. Open browser, enter about:config
b. Accept warnings, promises.
c. Double click the Preference Name network.negotiate-auth.trusted-uris.
d. In the values text box that pops up, enter http://,https://

********************************************************
Step-9: Testing
*******************************************************
1. Login as Administrator to SUST.IDM.COM domain on Windows Server 2003 machine.
2. Open IE browser. Enter http://avatar.red.iplanet.com:8080/opensso/UI/Login?module=winsso
3. You should see end user profile page for administrator in OpenSSO
4. Repeat test with Mozilla firefox and verify.


*******
NOTES:
*******

Expected OpenSSO debug file output:
------------------------------------
The debug file Authentication on OpenSSO should have the following snippet in "message" mode.
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:351 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
New Service Login ...
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:423 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Service login succeeded.
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:430 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
SPNEGO token:
60 82 04 f1 06 06 2b 06 01 05 05 02 a0 82 04 e5
30 82 04 e1 a0 24 30 22 06 09 2a 86 48 82 f7 12
01 02 02 06 09 2a 86 48 86 f7 12 01 02 02 06 0a
2b 06 01 04 01 82 37 02 02 0a a2 82 04 b7 04 82
.... REALLY BIG BLOB ...
d0 f1 bc e3 fc d0 2c 7a 59 a3 c8 2a 35 cc 71 f6
d9 cd e6 c0 2e bb 7e 37 c9 6e fd 1a bc 14 82 7e
fe a0 29 3b a7
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:431 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
token tag:60
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:431 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
SPNEGO OID found in the Auth Token
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:431 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
DerValue: found init token
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:431 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
DerValue: 0x30 constructed token found
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:435 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Kerberos token retrieved from SPNEGO token:
60 82 04 af 06 09 2a 86 48 86 f7 12 01 02 02 01
00 6e 82 04 9e 30 82 04 9a a0 03 02 01 05 a1 03
02 01 0e a2 07 03 05 00 20 00 00 00 a3 82 03 c2
.... REALLY BIG BLOB ...
bc e3 fc d0 2c 7a 59 a3 c8 2a 35 cc 71 f6 d9 cd
e6 c0 2e bb 7e 37 c9 6e fd 1a bc 14 82 7e fe a0
29 3b a7
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:435 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
In authenticationToken ...
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:452 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Context created.
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:489 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Token returned from acceptSecContext:
60 68 06 09 2a 86 48 86 f7 12 01 02 02 02 00 6f
59 30 57 a0 03 02 01 05 a1 03 02 01 0f a2 4b 30
49 a0 03 02 01 03 a2 42 04 40 04 60 a6 63 ef 08
b8 98 b6 69 f6 8a c5 7a 14 af b6 c3 03 1f 92 96
26 84 28 03 5e f8 6d 13 30 1b a4 d3 8d 17 4d 55
23 eb eb 8d c8 2e 56 46 a9 d2 a1 4f ec 10 3c 59
4b e9 34 15 ea 18 6a 40 68 7e
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:489 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Context establised !
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:490 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
User authenticated: Administrator@SUST.IDM.COM
amAuthWindowsDesktopSSO:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
WindowsDesktopSSO authentication succeeded.
amLoginModule:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Login NEXT State : -1
amLoginModule:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
amLoginModule:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
SETTING Module name.... :winsso
amAuth:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Module name is .. winsso
amAuth:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
successModuleSet is : [winsso]
amJAAS:03/24/2010 04:15:20:493 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
login success
amLoginModule:03/24/2010 04:15:20:494 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
AMLoginModule.commit():Succeed,principal=WindowsDesktopSSOPrincipal: Administrator
amLoginModule:03/24/2010 04:15:20:494 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
Done added user to principal
amJAAS:03/24/2010 04:15:20:494 PM PDT: Thread[httpSSLWorkerThread-8080-1,10,Grizzly]
commit success

Possible errors while configuring Windows Desktop SSO feature.

************
Problem-1:
************
Type:
-----
ktpass configuration on Windows Domain Controller.

Error:
-------
ktpass command gives error "Failed to retrieve user info if you configure it in two stages"

Solution:
----------
Use the following syntax to do both mapping and keytab generation in one step:

C:\userData\lakshman>ktpass /princ HTTP/avatar.red.iplanet.com@SUST.IDM.COM /pas
s Password123 +DesOnly /crypto DES-CBC-CRC /ptype KRB5_NT_PRINCIPAL /mapuser avata
r /out avatar.HTTP.keytab
Targeting domain controller: parrot.SUST.IDM.COM
Successfully mapped HTTP/avatar.red.iplanet.com to avatar.
Key created.
Output keytab to avatar.HTTP.keytab:
Keytab version: 0x502
keysize 67 HTTP/avatar.red.iplanet.com@SUST.IDM.COM ptype 1 (KRB5_NT_PRINCIPAL)
vno 3 etype 0x1 (DES-CBC-CRC) keylength 8 (0x98628cd615045bc8)
Account avatar has been set for DES-only encryption.

************
Problem-2:
************
Type:
-----
ktpass configuration on Windows Domain Controller.

Error:
-------
Executing ktpass command gives "DnsCrack error"

Solution:
---------
Do not have spaces in user name that you are trying to map. Make sure "Full Name" and Logon name does not have any spaces.

************
Problem-3:
************
Type:
-----
Specifying correct algorithm while running ktpass command.

Solution:
---------
If AM is using Java 1.5_08 or below, must use DesOnly and crypto as DES-CBC-CRC.
To avoid running into this algorith problems, always use DesOnly and DES-CBC-CRC for testing. This is supported on all java versions above and below 1.5_08.

************
Problem-4:
************
Type:
-----
Domain name on AD is not all capital letters like SUST.IDM.COM Instead it is sust.idm.com

Solution:
---------
This is acceptable and will work. Use capital letters as in example below while running ktpass command if domain name is small letters.
C:\userData\lakshman>ktpass /princ HTTP/avatar.red.iplanet.com@SUST.IDM.COM /pas
s Password123 +DesOnly /crypto DES-CBC-CRC /ptype KRB5_NT_PRINCIPAL /mapuser avata
r /out avatar.HTTP.keytab

windows cross-platform authentication + WinSSO auth module on AM/OpenSSO

1. When the logged-on user requests a resource from the Web server, it sends the initial HTTP GET verb.

2. The Web server, running the SPNEGO Token Handler code, requires authentication and issues a 401 Access Denied, WWW-Authenticate: Negotiate response.

3. The client calls AcquireCredentialsHandle()and InitializeSecurityContext() with the SPN to build the Security Context that requests the session ticket from the TGS(KDC).

4. The TGS/KDC supplies the client with the necessary Kerberos Ticket (assuming the client is authorized) wrapped in a SPNEGO Token.

5. The client re-sends the HTTP GET request + the Negotiate SPNEGO Token in an Authorization: Negotiate base64(token) header.

6. The Web server's SPNEGO Token Handler code accepts and processes the token through GSS API, authenticates the user and responds with the requested URL.





Process flow for Windows Desktop SSO module in AM code



1. When the logged-on user (browser client) requests a protected resource from the Web server, it sends the initial HTTP GET verb.

2. The policy agent intercepts the request, sees SSO token in cookie is not present. It redirects it to the web server hosting Sun Access Manager which has WinSSO auth module code (SPNEGO Token Handler code).

3. The Web server, running the SPNEGO Token Handler code (Access Manager Windows desktop SSO auth module), requires authentication to access that resource. So Access Manager code on web server issues a 401 Access Denied, WWW-Authenticate: Negotiate response to the browser client.

4. The browser client calls AcquireCredentialsHandle()and InitializeSecurityContext() with the SPN to build the Security Context. In this process, SPNEGO capable browser requests the session ticket from the Ticket Granting Server (TGS - could be windows domain controller or unix kdc server). This direct interaction between browser and KDC will provide
a) Ticket Granting Ticket (TGT - if not already present)
b) Kerberos or NTLM ticket depending upon configuration. Note AM works only with Kerberos ticket. AM does not support NTLM ticket.
This is wrapped in a SPNEGO token which is presented to AM.

5. The TGS/KDC supplies the client (browser) with the necessary Kerberos Ticket (assuming the client is authorized) wrapped in a SPNEGO Token.

6. The client re-sends the HTTP GET request + the Negotiate SPNEGO Token in an Authorization: Negotiate base64(token) header to Windows Desktop SSO module of Access Manager running on Unix web server.

7. The SPNEGO Token Handler code in Windows Desktop SSO module of Access Manager running on Unix web server accepts and processes the token through GSS API, authenticates the user. After successful authentication, AM prepares SSO Token in a cookie.

8. AM sends back response to browser with HTTP code - 200. Now browser has SSO Token wrapped in a cookie.

9. Browser sends HTTP Get request to web server hosting policy agent so that it can handle the protected resource request.


References:
===========
MSDN Article-1
MSDN Article-2
MSDN Article-3
OpenSSO doc Article-1