Solutions

User cannot log in using Push authentication in AM (All versions)

Last updated Dec 17, 2020

The purpose of this article is to provide assistance if a user cannot log in using Push authentication in AM.

Symptoms

The user cannot log in using Push authentication.

You see the following error when a user attempts to log in using Push authentication:

{"code":500,"reason":"Internal Server Error","message":"Authentication Error!!"}

An error similar to the following is shown in the CoreSystem debug log when this happens:

Formatted event: "de6427e2-4671-9359-aff9-bac00cd4c431-311","2018-03-04T12:21:28.554Z","AM-LOGIN-COMPLETED","de6427e2-4671-9359-aff9-bac00cd4c431-305",,"[""c3f6d35deec82a4031""]","FAILED",,,"[{""moduleId"":""pushAuth"",""info"":{""authIndex"":""service"",""failureReason"":""LOGIN_FAILED"",""ipAddress"":""203.0.113.0"",""authLevel"":""2""}}]","Authentication","/"

You may also see the following error in the Push debug logs:

Received error response: com.amazonaws.services.sns.model.EndpointDisabledException: Endpoint is disabled (Service: AmazonSNS; Status Code: 400; Error Code: EndpointDisabled; Request ID: 1431e de2-94b3-2d50-6e21-bc9c8f3931f7)

The endpoint referred to in this error is the end user's device (for example, mobile) endpoint.

Recent Changes

N/A

Causes

The majority of issues with Push authentication are caused by changes to the end user's device. Common reasons include (although not limited to):

The device has been restored from a backup.
The relevant app has been reinstalled on the device.
The user has disabled push notifications.

These changes result in the end user's device (endpoint) being disabled in AWS.

See Stack Overflow - Getting “EndpointDisabled” from Amazon SNS for information on other causes for the "Endpoint is disabled" error.

Solution

This issue, regardless of the exact cause, can typically be resolved by re-registering the device. This process initiates a search for the endpoint and results in it being re-enabled in AWS.

Note

Please observe the following when constructing REST calls:

Make the REST call to the actual AM server URL (not lb).
Change the name of the iPlanetDirectoryPro header to the name of your actual session cookie.
Set this session cookie header to the token returned when you authenticated.
Ensure the Accept-API-Version header contains a valid resource version.

See How do I avoid common issues with REST calls in AM/OpenAM (All versions)? for further information.

You can re-register the device as follows:

Authenticate as an admin user. For example:$ curl -X POST -H "X-OpenAM-Username: amadmin" -H "X-OpenAM-Password: cangetinam" -H "Content-Type: application/json" -H "Accept-API-Version: resource=2.1" http://host1.example.com:8080/openam/json/realms/root/authenticate?authIndexType=service&authIndexValue=adminconsoleservice Example response:{ "tokenId": "AQIC5wM2LY4SfcxsuvGEjcsppDSFR8H8DYBSouTtz3m64PI.*AAJTSQACMDIAAlNLABQtNTQwMTU3NzgxODI0NzE3OTIwNAEwNDU2NjE0*", "successUrl": "/openam/console", "realm": "/" }
Remove the device from the user's profile using the following curl command where myUser in the URL is replaced with the name of the user:$ curl -X POST -H "Content-Type: application/json" -H "Accept-API-Version: resource=3.0,protocol=1.0" -H "iPlanetDirectoryPro: AQIC5wM2LY4Sfcxs...EwNDU2NjE0*" http://host1.example.com:8080/openam/json/realms/root/users/myUser/devices/push?_action=reset
Ask the user to re-register their device.

Related Training

N/A

Related Issue Tracker IDs

OPENAM-12043 (Trigger SNS endpoint enablement when a recovery code is used)