I review the RSA Adaptive Authentication server logs on a daily basis and seldom find three error messages I don't understand:
Reason Code: 1203 Invalid/Expired/Reset Session ID
Reason Code: 1502 User is not enrolled
Could not decrypt/unwrap device token
I tried to reproduce these errors in my test environment but to no avail.
Hi Lyndal,
Thank you so much for your reply. It was really helpful.
I was able to reproduce the "Reason Code: 1203 Invalid/Expired/Reset Session ID " Error. Our step-up authentication is outside of Adaptive Authentication so the session timeout in Back Office doesn't apply to us. Apparently the Session ID is created by AA on the ANALYZE response and when we wait 30+ minutes to send the NOTIFY request with the same Session ID, AA rejects it. Not sure why it's doing that.
Still can't reproduce the "Reason Code: 1502 User is not enrolled" Error. I stepped through the enrollment process for an unenrolled user and didn't see the error. We don't perform ANALYZE calls on unenrolled users so it wouldn't be a logic problem. We also don't unenroll active users.
Looking at the SOAP logs for the "Could not decrypt/unwrap device token", it looks like some the SOAP requests are appending "WFXXProbe" to the device token, which causes the error. Have you've ever seen anything like this before?
Thanks again.
Reason Code: 1203 Invalid/Expired/Reset Session ID " Error
In the NOTIFY request, are you setting the eventReferenceID ? It should be set to the transactionID number that was returned by AA on the ANALYZE response. eventReferenceID should be set when the NOTIFY eventType is EXTRA_AUTH. Reference: RSA Adaptive Authentication (On-Premise) 7.3 API Reference Guide, chapter 5 "Web Services Request Data Structures and Types", section "eventData Structure", row "eventReferenceID". In the same chapter, see also section "identificationData", row "transactionId".
"Reason Code: 1502 User is not enrolled
Although the application does not intend to perform ANALYZE for unenrolled users, it is possible there is a bug in the application that allows that to happen in some circumstances. Have you considered investigating less common logic paths, such as if an end user is unenrolled from the Back Office? To be sure, you can check a user's account history, including whether they are currently enrolled, in the AA Back Office. Refer the RSA Adaptive Authentication (On-Premise) 7.3 Back Office User’s Guide, chapter 5 "Managing End-User Accounts".
Could not decrypt/unwrap device token
I could not find any record of "WFXXProbe" being seen in device tokens. The addition of "WFXXProbe" to some device tokens sounds like it may be an application bug when your application is building the SOAP request. To confirm if the correct device token is being sent, capture what is returned as a device token from the user's browser to the application, and compare that to what the application sends for the device token in the SOAP request to AA. Both values should be the same with no extra data inserted.
Hi Lyndal,
Reason Code: 1203 Invalid/Expired/Reset Session ID " Error
Yes, I am setting the eventReferenceID value in the Notify Request message with the transactionID from the Analyze Response message. Am able to consistently reproduce the error after waiting for 30+ minutes with the step-up authentication. Think it might be a web session timeout issue. After waiting 30 minutes, the user enters the correct step-up authentication credentials and is granted access, however in the case management application the user is showing as failed step-up authentication.
"Reason Code: 1502 User is not enrolled
We don't unenroll users so I can't see there being a scenario where we perform a risk call for invalid users.
Could not decrypt/unwrap device token
Most of these cases is happening in our test environments where we run automated scripts to bombard our web portals. Not sure if this is causing the error. As of now, we have been unable to reproduce this issue consistently.
Thanks again for your feedback. It's really helpful.
Patrick
Hi Patrick,
thanks for your feedback.
Have a read of the RSA Adaptive Authentication (On-Premise) 7.x Workflows and Processes Guide for your AA version. Refer chapter 8 "Extra Credential Workflow" and chapter 9 "Client-Managed Authentication" to understand how timeouts and sessions should work for this flow. Specifically, in chapter 8 it states:
You should be aware of the following time-out configuration issues that are relevant to all authentication methods:
In chapter 9 it states "If your application does not inform Adaptive Authentication of the result of your authentication, it is as if the challenge is abandoned. The activity is marked as suspected fraudulent in the Case Management application.".
Reason Code: 1203 Invalid/Expired/Reset Session ID " Error
Check the information in the above chapters to understand how timeouts and sessions and fraud notifications work. As you are doing a load test, bear in mind it is possible that Maximum Open Sessions per User has been reached and a session isn't being created.
Reason Code: 1502 User is not enrolled
Review the end user's account history in Back Office, to confirm their enrolment status at the time of the authentication. If there is no record of the user, then it means the end user has never have been enrolled.
Could not decrypt/unwrap device token
If tracing on the device where you run the scripts is not practical, you could run the load tests with a tracing tool listening on the same network segment, to capture the traffic between the automated scripts and the web portals. There are tracing tools that will decrypt encrypted traffic for you if you can configure them with the private key.
regards
Lyndal
Hi Patrick,
the Reason Codes are documented in the RSA Adaptive Authentication (On-Premise) 7.x Web Services API Reference Guide (versions v7.1 and earlier) or the RSA Adaptive Authentication (On-Premise) 7.x API Reference Guide (versions v7.2 and later), in Appendix "API Error Messages".
These and other manuals for currently supported RSA Adaptive Authentication on Premise (AAoP) versions are available on the RSA Link RSA Adaptive Authentication Documentation pages.
For these messages (info in italics is from the v7.3 manual):
Reason Code: 1203 Invalid/Expired/Reset Session ID
The error code is issued when either the session Id is invalid or the session is expired. As a result, the processing error prevents successful completion of the SOAP request . This could indicate nothing has been sent from the application to RSA Adaptive Authentication On Premise (AAoP) for a while for the session, and the session timed out on the server. Check the timings in the log of previous messages for the session. Compare that to authentication method timeouts configured in the Administration Console. The session timeout settings and their default values are documented in the RSA Adaptive Authentication (On-Premise) 7.x Operations Guide (also available on RSA Link RSA Adaptive Authentication Documentation pages), section "Authentication Methods Parameters". The other possible cause is that the application has a logic error causing it to send the wrong session id for the user's session, or is sending events for an expired or reset session.
Reason Code: 1502 User is not enrolled
The user is not enrolled in the Adaptive Authentication system. If your application is designed to allow unenrolled users to attempt to authenticate with AAoP, this message is expected in that circumstance and so can be ignored. If your application is not expected to allow unenrolled users to attempt to authenticate with AAoP, then there is a logic error in your application that has allowed the attempt.
Could not decrypt/unwrap device token
See this RSA Knowledgebase Article for possible cause: 000021674 - Explanation for AA log file errors . Other possible causes are a logic error in your application causing it to send a wrong or corrupted/invalid device id to AAoP for the user's device, or a corrupted/invalid cookie or FSO on the end user's device.