Login to AM (All versions) fails with valid username/password after enabling Secure cookies

Last updated Jan 16, 2023

The purpose of this article is to provide assistance if login to AM fails for all users (including amAdmin) even though they are using valid credentials. This issue occurs when you are using a non-SSL connection and you have enabled Secure cookies.

Symptoms

When logging into AM using an HTTP connection, login fails but you remain on the login page and a "Login/password combination is invalid." message is displayed.

This issue can affect both administrators (preventing access to the AM admin UI) and users (preventing access to pages such as the User profile). Often it will seem to only affect administrators, with users still able to log in. This happens because users are often connecting to a HTTPS connection, whereas the administrator is attempting to use an internal non-secured network.

An error similar to the following is shown in the restAuthenticationFilter debug log:

restAuthenticationFilter:07/26/2015 12:41:11:165 PM EDT: Thread[http-bio-8080-exec-7,5,main] Filter init param, context-factory-class, not set. Falling back to the DefaultServerContextFactory. restAuthenticationFilter:07/26/2015 12:41:11:173 PM EDT: Thread[http-bio-8080-exec-7,5,main] Filter init param, audit-api-class, not set. Falling back to the NoOp Audit Api. restAuthenticationFilter:07/26/2015 12:41:11:183 PM EDT: Thread[http-bio-8080-exec-7,5,main] Created module, className: org.forgerock.openam.jaspi.modules.session.OpenAMSessionModule restAuthenticationFilter:07/26/2015 12:41:11:585 PM EDT: Thread[http-bio-8080-exec-7,5,main] Finished initialising the DefaultRuntimeInjector restAuthenticationFilter:07/26/2015 12:41:11:586 PM EDT: Thread[http-bio-8080-exec-7,5,main] Filter init param, runtime-injector-class, not set. Falling back to the DefaultRuntimeInjector. restAuthenticationFilter:07/26/2015 12:41:11:586 PM EDT: Thread[http-bio-8080-exec-7,5,main] Initialising the JaspiRuntime restAuthenticationFilter:07/26/2015 12:41:11:603 PM EDT: Thread[http-bio-8080-exec-7,5,main] OpenAMSessionModule has successfully authenticated the client restAuthenticationFilter:07/26/2015 12:41:11:603 PM EDT: Thread[http-bio-8080-exec-7,5,main] Setting principal name, null, and 0 context values on to the request. restAuthenticationFilter:07/26/2015 12:41:11:604 PM EDT: Thread[http-bio-8080-exec-7,5,main] Successfully validated request. restAuthenticationFilter:07/26/2015 12:41:11:918 PM EDT: Thread[http-bio-8080-exec-7,5,main] Successfully secured response. restAuthenticationFilter:07/26/2015 12:41:11:992 PM EDT: Thread[http-bio-8080-exec-8,5,main] OpenAMSessionModule has failed to authenticated the client, passing to Auth Modules restAuthenticationFilter:07/26/2015 12:41:11:993 PM EDT: Thread[http-bio-8080-exec-8,5,main] Auditing authentication result restAuthenticationFilter:07/26/2015 12:41:11:995 PM EDT: Thread[http-bio-8080-exec-8,5,main] Authentication has failed. restAuthenticationFilter:07/26/2015 12:41:11:998 PM EDT: Thread[http-bio-8080-exec-8,5,main] Access Denied org.forgerock.jaspi.exceptions.JaspiAuthException: Access Denied at org.forgerock.jaspi.runtime.context.ContextHandler.handleCompletion(ContextHandler.java:131) at org.forgerock.jaspi.runtime.context.JaspiServerAuthContext.validateRequest(JaspiServerAuthContext.java:244) at org.forgerock.jaspi.runtime.JaspiRuntime.processMessage(JaspiRuntime.java:160) at org.forgerock.jaspi.JaspiRuntimeFilter.doFilter(JaspiRuntimeFilter.java:131) ...

You can use your browser's developer tools to view the HTTP Headers; you will notice that the first POST call to authenticate (/json/authenticate) is successful, whereas the second POST call to retrieve the ID (json/users?_action=idFromSession) fails with a 401 Unauthorized response:

{"code":401,"reason":"Unauthorized","message":"Access Denied"}

Recent Changes

Enabled Secure cookies (com.iplanet.am.cookie.secure=true) but did not implement secured (HTTPS) connections for all communications with AM. This could occur for example, if you were testing SSL or had only partially implemented SSL for AM.

Causes

If you have enabled AM to set cookies in secure mode, the browser will only return the session cookie if a secure protocol such as HTTPS is used; the cookie will not be returned over non-SSL connections. Although you have successfully authenticated, the cookie containing the session token is not passed to AM, which prevents the login from succeeding.

Solution

This issue can be resolved by either using a secured HTTPS connection to access AM or by disabling Secure cookies. The approach you take depends on your plans for SSL.

If you have enabled SSL in AM, you can access AM using a secured HTTPS connection, where the login URL for the AM admin UI would be similar to this: https://am.example.com:8443/am/XUI/#login/
If you have not enabled SSL, you should disable Secure cookies. Given that the AM admin UI is unaccessible, you must do this via ssoadm by entering the following command: $ ./ssoadm update-server-cfg -u [adminID] -f [passwordfile] -s [server] -a com.iplanet.am.cookie.secure=falsereplacing [adminID], [passwordfile] and [server] with appropriate values, where [server] is 'default' or the server name depending on how you configured SSL.

Note

You must restart the web application container in which AM runs to apply these configuration changes.

Related Training

N/A

Related Issue Tracker IDs

N/A