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 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).
Shorten the timeout value of the refresh token issued as part of OAuth Resource Owner Password Grant
. The com.netiq.idm.osp.oauth.public.refreshTokenTTL property in ismconfiguration.properties file specifies the timeout of this refresh token. After setting the value, restart the Tomcat server where OSP is deployed. The timeout is set to 2,592,000 seconds or 30 days by default, after which OSP automatically removes the login entry.
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.