Allow users in a locked state due to max login failures (disabled flag = 2) to perform SP initiated SSO

[Dylan Coleman]

Hello,

We have a new business requirement to allow users in a locked state due to login attempt failures (Disabled Flag = 2) to perform SAML 2.0 based SSO when we are acting as Service Provider (SP) in a federation partnership. 

Currently, when an active user performs SP initiated SSO, we provide the user an SP initiated URL:

Example: https://federate.exampledomain.com/affwebservices/public/saml2authnrequest?ProviderID=ExampleIdP&RelayState=https://intendedtarget.com

When the user clicks this URL, a SAML2 authentication request is sent to the IdP, and the user is redirected to the IdP SSO service URL to provide their credentials. After a successful authentication at the IdP, the user is then redirected back to the SP (us in the case) assertion consumer URL before ultimately being redirected to the RelayState specified in the authentication request.

However, when a locked user attempts this same SP initiated SSO flow, after being authenticated at the IdP, they are being redirected back to the SP assertion consumer URL and instantly being redirected to the redirect URL specified in our password policy.

From what I can tell in the FWSTrace.log, it appears the transaction is failing at the step where our SAML consumer service validates the assertion and then makes a login call to the Siteminder policy server (CHECKPOINT = SSO_RESPONSEMESSAGEINLOGIN_REQ). The resulting response from Agent API login call is 2, and the login fails (CHECKPOINT = SSO_LOGINFAILURE_RSP). Then, the user is redirected to the redirect URL specified in our password policy because of the response from the failed login call to the policy server. 

Since it is ultimately the IdP performing the user authentication in this transaction, we want to allow users to successfully perform an SP initiated SSO even if the account is in a locked state.

Is it possible to accomplish this? And if so, what would be the best way to go about implementing this?

I apologize if my understanding of this scenario is incorrect, as I am still learning. Feel free to correct me on any point if it seems that I am confused.

Any help is appreciated!

Thanks

[Hongxu Liu]

Hi Dylan,

Please See referenced tech note explaining the Agent API error:
https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=45157

Sm_AgentApi_LoginEx, is function call of agent. This function has -1 or -2 error code return.
*-1 means that webagent failed to communicate with the policy server
*-2 means connection timeout

'Sm_AgentApi_IsProtectedEx' is also a function call of agent to check whether accessed resource is protected or not.
Error code return:-
*-1 indicates that the Policy Server could not be reached.
*-2 indicated Policy Server connection is timeout.
These are quite generic error messages. These basically indicate that..

Either the Policy Server was down
*OR* was not responding to the agent due to being busy and lack of resources and as a result the agent request timeout occurs
The agent request is not reaching to the policy server or the request is timing out, due to network latency.

As SP, it trusts IDP side decision on user identity. The decision from IDP side has to be successful, in order to SP to proceeds further.
Otherwise, there is no point contacting IDP in the first place.  If IDP has decided that the user account is Disabled or locked (not verifiable based on data provided), then transaction should stop here, otherwise it is a security violation. If SP decided that the user account is Disabled or locked, then transaction should not continue either, you should focus on resolving user account state.

Thank You,

Hongxu Liu