000034603 - Users seem to be challenged while method blocked, or not authenticated when they should in RSA Adaptive Authentication (Hosted) 11

Document created by RSA Customer Support Employee on Jan 4, 2017Last modified by RSA Customer Support Employee on Apr 22, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000034603
Applies ToRSA Product Set: Adaptive Authentication (Hosted)
RSA Product/Service Type: Adaptive Authentication (Hosted)
RSA Version/Condition: 11
IssueUsers are getting authenticated when their Authentication method is blocked 
There are two scenarios that can happen:
  1. User is locked for authentication and therefore the transaction is declined.  (As in these two user cases)
  2. User was asked to authenticate and closed the browser before any indication to AA was sent to which authentication method user was asked to challenge with.
Example customer case description --  The FI said this is unusual behavior for them to see. They are inquiring if a change or problem may exist that caused this issue. User Blocked but Bank Audit Trail shows successful logins in between.  
CauseRSA has identified the cause  from reviewing the SOAP API calls coming from the user transaction history, we have seen where data elements in SOAP are missing or not utilitzed by the customer online banking code.
  1. Not managing blocked users scenario properly - User is allowed to proceed and not decline.
  2. In some scenarios which require further investigation on customer side, the response to authenticate is ignored.
ResolutionCustomer Support Engineer should do the following:
1. Ask the customer for 1 or 2 sample user ids, then obtain a transaction user history for last 90 days that includes, the authentcation and user log extracts. 
2. Ask the customer for sample SOAP messages either from a test user that has demonstrated the issue or from the sample users provided that are showing this issue. 
3. Ask the customer to try to reproduce the issue in their UAT enviornment. 
4. Customer Support Engineer should evaluate the transactions and SOAP message, asking senior CSEs, or Engineering with a Jira ticket for assistance, if required.  
Look for the block after failed authentications and or the transactions.
|N/A |R | 9999| | | | | | | | | | | | | | | |
which indicate the RSA system has requested(REDIRECT_AUTHENTICATE) an authentication but it never initialized on the customer side. (and may then be considered a failure by the system.)    Also this condition may be indicated by a authentication result of OTHER, which is neither success or failed. 
Attached is a sample of a SOAP Analyze call with all the elements that should be included and utilized for a blocked user and noting the userStatus, which also should be reviewed by the customer code to take action on a blocked user. 
NotesThis is primarily an issue with the Client API and how it is handled by the customer, RSA Customer Support may help up to a certain point, but it may need to go to Professional Services if there is considerable rework required, that the customer would want RSA to assist.