The Identity Applications server supports APIs that expose all OAuth functionalities as endpoints for obtaining access tokens, and so forth.
The following is an example of the authentication sequence:
GET http://<ip address/DNS name of identity applications>:8180/idmdash/
Result: 200 text/html
The query includes a bunch of requests to obtain stylesheet (css), JavaScript, and so on.
The Landing Page makes a request to Identity Applications with no authorization header as the landing page has no access token.
GET http://prvdvnam850.namdom025.lab:8180/IDMProv/rest/access/users/fullName
Authorization header: none
Result: 401 error
As Identity Applications do not yet have an OAuth access token, it responds with a 401 error. This causes the Landing page to go to OSP to get an access token. Note that there are no OSP cookies yet.
GET http://<ipaddress>:8180/osp/a/idm/auth/oauth2/grant?response_type=token&redirect_uri=http:// <ipaddress>:8180/landing/com.netiq.ualanding.index/oauth.html&client_id=ualanding&state=spiffystate0.7645864660083901
Result: 200 text/html (The resulting page is the OSP login page)
The query includes a bunch of requests to obtain stylesheet (css) and favicon.
The result of the request to OSP (from the browser's point-of-view) is that a page is displayed with entry fields for the user's name and password. There are also cookies returned from OSP with the login page that will be sent by the browser in subsequent requests.
POST http://<ipaddress>:8180/osp/a/idm/auth/app/login?acAuthCardId=np-contract-{%24default-card}&sid=1
Cookies: JSESSIONID 95...79 End Of Session
x-oidp-oauth2-1449687159117—1013136951 "Wtf...zx0~" End Of Session
x-oidp-session59303d34382c2d310 200-GX0...97kISI~ End Of Session
Result: 302 Redirect to OSP implicitcontinue
GET http://<ipaddress>:8180/osp/a/idm/auth/oauth2/implicitcontinue?privateId=bb5b94976815f348307b&client_id=ualanding&irdpkg=1449687159117--1013136951
Cookies: JSESSIONID 95...79 End Of Session
x-oidp-oauth2-1449687159117--1013136951 "Wtf...zx0~" End Of Session
x-oidp-session59303d34382c2d310 200-PP+...RzX0F6 End Of Session
Result: 302 Redirect to Identity Manager landing OAuth result page
After an internal redirect between the OSP pages, the result is a redirect to the redirect_uri parameter that was originally sent with the initial request to OSP.
GET http://<ipaddress>:8180/idmdash/oauth.html
Cookies: x-oidp-session59303d34382c2d310 200-AZ...b/HQ~~ End Of Session
Result: 200
A fragment containing the access token (see section 4.2.2 of RFC 6749) is appended to the URL. The Landing page extracts the OAuth access token from this fragment. You cannot see this fragment because HTTP does not capture it.
The Landing Page again makes the “who am I” request, but this time with an authorization header as the Landing page has an access token.
GET http://<ipaddress>:8180/IDMProv/rest/access/users/fullName
Authorization header: Authorization bearer eHw...343
Result: 200 {"dn":"cn=mary,ou=users,o=data","name":"Mary Contrary"}
OSP creates oidpInstanceData attribute (Case Ignore, Single Valued String) for a user when the user logs in to the identity applications for the first time through OSP. OSP modifies this attribute each time a user logs in and out of the identity applications.
When a user is logged in, OSP adds a login entry to the attribute in base64 encoded and encrypted value format.
When the user logs out, OSP removes or modifies the login entry. When the user logs in again, OSP updates the entry. When the user logs out, OSP removes that login entry from the attribute.
When the user logs in again, OSP updates the entry. When the user logs out, OSP removes that login entry from the attribute.
When the user closes the browser instead of logging out, OSP does not remove the login entry because closing the browser does not involve a logout action. If the user continues to log in without logging out, the size of the entry grows large. This prevents OSP from updating the attribute and causes login failure for the user.
Note that a logout operation can only remove the entry for the login it is mapped or matched to. For example, if a user logs in three times and does not log out for these logins, and if the user logs in and out one more time, OSP removes this login entry.
If a user is not required to log out from the identity applications, perform one of the following actions to manage the size of the oidPInstancedata attribute:
Shorten the validity period of the login entry for the user. This allows OSP to automatically remove the login entry for the user. The validity period is controlled by Refresh token lifetime (hours) setting for OSP in the ConfigUpdate utility. The default value to store a login entry is 48 hours (2 days). After making the change in the ConfigUpdate utility, restart the Tomcat server where OSP is deployed.
Periodically delete the oidpInstanceData attribute from the user by using an LDAP based tool (iManager, jXplore, Apache Studio, and so on).
OSP cannot update the oidpInstanceData attribute for a user if one of the following conditions is true:
When the attribute is full with user’s login entries.
When the user logs in again, OSP fails to update the attribute with the new login entries because of insufficient space to store the entries. However, you can change the maximum length for storing the login entries based on your requirement.
The user does not does not have sufficient rights in the Identity Vault.
The OSP schema has not been extended in the Identity Vault and the user does not have this attribute.
To manually renew or extend the validity of the expired certificates, refer NetIQ Identity Manager Certificate Management Guide.
If you have configured SAML 2.0 as the authentication method for single sign-on access to the Identity Applications, you can direct the users to the dashboard landing page after logout. You can configure this setting in the ConfigUpdate utility (/opt/netiq/idm/apps/configupdate/) by setting the Landing page value to External and specifying your dashboard URL (https://<serverip:port>/idmdash/) in the Authentication tab. As a result, when a non-administrator user accessing the idmadmin page logs out of the application, they will be directed to the dashboard landing page automatically.
Additionally, to prevent non-administrator users from accessing the idmadmin component on Dashboard, the application displays a warning message whenever a user tries to access the idmadmin page without authorization. The application then directs the user to the dashboard landing page.
Issue: When you configure the Identity Applications for single sign-on with NetIQ Access Manager (NAM) or Active Directory Federation Service (AD FS) as an authentication service, then the Dashboard session will not terminate even after the session expires. This issue is observed because the default session timeout values for the Identity Applications, NAM, and AD FS are different.
Workaround: Ensure that you set the same session timeout values for all the sessions. For example, 20 minutes. To set the session timeout value for Identity Applications, see Authentication Configuration in the NetIQ Identity Manager Setup Guide for Linux or Authentication Configuration in the NetIQ Identity Manager Setup Guide for Windows.
To set the session timeout for NAM, perform the following actions:
Open the Administration Console for Access Manager.
Navigate to Devices > Identity Servers > IDPCluster and click Edit to modify the cluster configuration.
In IDPCluster, go to Local > Contracts and select the contract between the Access Manager and Identity Manager.
In the General tab, specify the Authentication Timeout value in minutes.
Click Apply.
To set the session timeout value for AD FS, perform the following actions:
(Conditional) To set the session timeout from the command line:
Launch the Windows PowerShell application on the server where Identity Applications is installed.
Execute the following command:
Set-ADFSRelyingPartyTrust [-Targetname <relying_party>] [-TokenLifetime <Int32>]
where,
-Targetname: Specifies the name of the relying party trust that is used to connect to the AD FS.
-TokenLifetime: Specifies the duration (in minutes) for which the claims that are issued to the relying party are valid (that is, the session timeout).
(Conditional) To set the session timeout from the AD FS user interface,
Open Microsoft AD FS Management console.
Right-click Service and then select Edit Federation Service Properties.
In the General tab, specify the Web SSO lifetime value in minutes.
Click Apply.