Application Delivery Management
Application Modernization & Connectivity
CyberRes
IT Operations Management
(attached - NetIdentity-312.zip)
The ability to single sign on (SSO) to NetIdentity aware Web applications was available with Novell's iChain product. Novell Access Manager, the successor to the iChain product, does not include any NetIdentity authentication profile or class. The attached jar file offers the ability to SSO to Access Manager from NetIdentity enabled workstations. This document describes the requirements and configuration steps required to get NetIdentity SSO to Access Manager, and describes the NetIdentity protocol exchange during authentication.
For NetIdentity to work with Novell Access Manager, the assumption is that you have an Access Gateway proxy service with a protected resource that is using a NetIdentity enabled contract. A workstation with the NetIdentity client needs to access a Web server through this NetIdentity enabled protected resource. When this happens, the Access Gateway generates a Liberty authentication request that includes the NetIdentity contract type, and redirects the browser to authenticate to the Novell Identity (IDP) server.
The browser sends a GET request to the NIDP server, which does not include a valid session cookie because the workstation is not yet authenticated to the Novell IDP server. Because the workstation has NetIdentity installed, the GET request includes a header with the value NovINet: v1.2.
When the IDP server receives the GET, replies with a 401 Unauthorized packet. This packet includes NetIdentity specific information such as NetIdentity Realm name and other information used by the NetIdentity protocol. When the NetIdentity client receives this information, if Strict Trust is enabled (default), NetIdentity verifies that the server and Certificate Authority (CA) are trusted (according to the list of trusted authorities in Internet Explorer). If the server and CA are trusted, NetIdentity checks its existing credential store (i.e. “wallet”) to see if authentication credentials already exist for that Realm name.
If they do exist, they are sent back to the IDP server in attempt to authenticate. If the wallet credentials do not exist for that realm name, and the NetIdentity registry setting called Try Local Credentials is enabled, the user's desktop login credentials are sent. If no entry exists in the wallet for this realm and Try Local Credentials is disabled or fails, the NetIdentity client provides a pop-up dialog prompting the user for login credentials. The NetIdentity pop-up dialog color scheme differs from that of the browser's pop-up dialog (as shown in Figure 1 below). As soon as the users credentials are entered and applied, the credentials are added to the NetIdentity wallet for future consumption.
Figure 1: NetIdentity pop up window
# Configuration requirements
# Configuration steps
Figure 2: Creating a new authentication class
The Administrator has the ability to specify the following class paths - BasicClass, PasswordClass (in the case of HTTP protocol between browser and proxy), ProtectedBasicClass, and ProtectedPasswordClass (in the case of SSL between browser and proxy) with Netidentity. In each case, the classes check for the presence of the NetIdentity client, and if present call the NetIdentityClass for authentication. In the case where no NetIdentity client exists, we perform the originally named authentication. In the example setting above with the ProtectedPasswordClass, the user would get prompted for their username and password in a login form over HTTP if no NetIdentity client was identified on the workstation.
Figure 3: Adding NetIdentity authentication classpath
Figure 4: Adding NetIdentity authentication class Realm details
Figure 5: Creating NetIdentity specific Method.
Figure 6: Creating NetIdentity specific Contract
Figure 7: Assigning NetIdentity contract to Access Gateway protected resource
Once all the changes have been applied at both the IDP and Access Gateway servers, all that is required is to hit this protected resource from a workstation running the NetIdentity client.
The following flow shows the HTTP requests and responses when authenticating directly to the IDP server from a workstation running the NetIdentity client.
// 1. Request from browser to IDP server login page - NetIdentity X-NovINET header included
GET /nidp/app HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Host: idpcluster.lab.novell.com:8443
Connection: Keep-Alive
X-NovINet: v1.2
// 2. Response from IDP server requesting NetIdentity credentials for LINUXLAB5_TREE realm
HTTP/1.1 401 Unauthorized
Set-Cookie: JSESSIONID=5845143E924D4FF3EEC1514A5ECF0E4B; Path=/nidp; Secure
WWW-Authenticate: Novell realm="LINUXLAB5_TREE", nonce=iaKI2Gub0Q8=, guid=pWwy/tKI8tL/wuczG1pmKQ==
Content-Length: 1590
Date: Tue, 20 May 2008 14:25:08 GMT
Server: Apache-Coyote/1.1
// 3. Assuming the NetIdentity credentials available on client (from the NetIdentity wallet), we send them via the Authorization header in response. If credentials not available, we submit them via the popup and save them to be used next time around.
GET /nidp/app HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Host: idpcluster.lab.novell.com:8443
Connection: Keep-Alive
Authorization: Novell realm="LINUXLAB5_TREE", novellsession1=AQABAQEAAQQ=, response=MYTNlMzteJqT2e5QBrqx6TOKB8M5Joy14vIOcuG79F4xGadI8QO1 QHRmJzn77nzk7fORkgDOQ=:Dib1GZd5LL wPB4gib0oUPEySwdRPHJ2YjsYaXUxqAdBHknjca pd3 B9Ns4RklySImBY3Ny4c9q3zkupUMNspfDTtrmbRXl02RUci C0g /6UdgCTV1ZLBke45N3pjZ09uK ILfkmjG2rYDj8VtIFvATyysXt7w2cRGrJJYsvM=, hmac=Pwon7foxaiMdJ GZJIP6ET9TYQM=, nonce=qaWvOvAC zw=
Cookie: JSESSIONID=5845143E924D4FF3EEC1514A5ECF0E4B
X-NovINet: v1.2
// 4. Response from IDP server redirecting browser back to origin URL after validating the credentials
HTTP/1.1 302 Moved Temporarily
Authentication-Info: Novell realm="LINUXLAB5_TREE", challenge=odWog7BIuHXlDW2A2/ZvGA==, novellsession1=AQABAQEAAQQ=, novellsession2=AQABAQ==, hmac=iWhd/Ft5Y47DQs/cSF8KCAULRPw=
Location: https://idpcluster.lab.novell.com:8443/nidp/app
Content-Length: 0
Date: Tue, 20 May 2008 14:25:08 GMT
Server: Apache-Coyote/1.1
// 5. Request from browser for the origin URL. Includes Authorization header with credentials and X-NovlNET NetIdentity headers.
GET /nidp/app HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Host: idpcluster.lab.novell.com:8443
Connection: Keep-Alive
Cookie: JSESSIONID=5845143E924D4FF3EEC1514A5ECF0E4B
X-NovINet: v1.2
Authorization: Novell realm="LINUXLAB5_TREE", hmac=h1vw2pSpSVPk8O4U8ZeCQ8coGxw=, novellsession1=AQABAQEAAQQ=, novellsession2=AQABAQ==, nonce=kDZ6ohCr6b4=
// 6. Successful response from IDP server.
HTTP/1.1 200 OK
Pragma: No-cache
Cache-Control: no-cache
Content-Type: text/html;charset=utf-8
Content-Length: 785
Date: Tue, 20 May 2008 14:25:08 GMT
Server: Apache-Coyote/1.1
Chris Seamons
Micro Focus Community Management
If you find this post useful, give it a 'Like' or use 'Verify Answer'.