AnsweredAssumed Answered

CA Single Sign-On manage fail authentication responses

Question asked by Serkera on Jun 6, 2018
Latest reply on Jun 11, 2018 by Serkera

Hello,

 

I'm working in a response configuration which I want to use to manage the authentication failures (wrong password, user not found, access denied, etc.)

 

In my desing, I have a login page deployed at a non protected zone.
This page posts the user credentials to siteminders fcc page "forms/login.fcc".

If the credentials are OK, Siteminder redirects me to my service page (deployed in the protected zone) - this is my "happy path" and it is working just fine.

 

However, when the authentication fails, I'm redirected to my login page (non protected zone) and I want to consume the response added on the OnAuthAttempt / OnAccesReject / OnAuthReject events. Until now, the only way I managed to make it work was using a cookie variable (WebAgent-HTTP-Cookie-Variable) - but I dont want to use cookies.

 

In my desing, I was hoping to use a WebAgent-HTTP-Header-Variable (or maybe a WebAgent-HTTP-Authentication-Variable) to do it. But for an unknown reason, this values never gets back to my page at the non protected zone.

 

I was hoping to get your advise about :
* why this approach is not working? Am I able retrieve a header response attribut in a non protected zone?
* what would be the best practice (according to CA) to return a code or the raison of the failure to my login page? By the way, the variable SM_AUTHREASON always returns 0 even when the authentification fails.

 

PS 1 : I checked the smtracelog and I can clearly see that the response was activated and the values were added ... I just can't see them neither in the http response context, nor in the http request context.

 

 

PS 2 : I've also tried to work on the approach described on this link, and it also didn't work : https://communities.ca.com/thread/241737436

 

Chad

 

As per current design of CA SSO / SiteMinder.

 

  1. If user has a valid SMSession on the Browser. On unprotected resources, User would be able to see Only Default SiteMinder Headers. User would not have access to Headers being passed by Responses. Remember the WebAgent is only a PEP (Policy Enforcement Point) and Policy Server is PDP (Policy Decision Point). If a Resource is defined as unprotected within Policy Server OR is not defined within Policy Server; it is evaluated as an unprotected resource by Policy Server. This is then communicated to WebAgent. WebAgent simply ignores these resources if the IsProtected() API call returns unprotected from WebAgent Cache or from Policy Server. Therefore there is no Reponse Headers. To put it in other terms, it is as good as SiteMinder isn't there intercepting / challenging / validating.

 

Best regards,
Marcos

Outcomes