Symantec Access Management

  • 1.  CA SSO Re-Authenticate on Sensitive Data/ Resource

    Posted May 03, 2018 11:10 AM

    Hi All,

     

    I was just going through below documentation How to Require Re-authentication for Sensitive Resources - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation , but unable to use this functionality as stated.

     

    Below are my configurations:

     

    1) Protected Realm as "webagent/test" 

    2) Created a policy as "test policy"

    3) Under this policy, created a rule as "test GET/ POST" marking the sensitive data as "webagent/test/transfer.html", marking action as only GET & POST.

    4) Under this policy, created another rule as "test onAccessValidateIdentity" marking the same sensitive data as "webagent/test/transfer.html", marking action (Authorization events as onAccessValidateIdentity) 
    5) Added a response as HTTP-Validate-Redirect for test onAccessValidateIdentity with value of the custom relogin.fcc

    6) Restarted the Policy Server.


    But when I try to access either webagent/test or webagent/test/transfer.html both are redirecting me to the Protected Realms - Authentication scheme location i.e. login.fcc, once I give correct credentials, it is giving me access for both test and test/transfer.html 

    Need help, on how to actually do a re-auth on sensitive data.

     

    WE ARE ONLY DOING AUTHENTICATION from CA SSO, have disabled Authorization and FCCCombat.



  • 2.  Re: CA SSO Re-Authenticate on Sensitive Data/ Resource

    Posted May 03, 2018 12:33 PM

    Prateek

     

    The reason it is not working is because, the feature is probably working on authorization layer. 

     

    Remember Policy = Authorization.

     

    Did you for testing purpose enable Az and see if in that case did it work.



  • 3.  Re: CA SSO Re-Authenticate on Sensitive Data/ Resource

    Posted May 04, 2018 04:03 AM

    I did the above change in ACO by enableAuthorization, but now my Webserver having agent configuration is not getting up properly.

    Getting Internal Server Error.

     

    On more analyisis, i can see errors as below:
    Session cache failed to initialize.

    SmCacheBase failed to initialize.

     

    Failed to attach to the authorization cache. Please verify that the LLAWP process is running.

    Siteminder agent has encountered initialization errors and will not service requests. 



  • 4.  Re: CA SSO Re-Authenticate on Sensitive Data/ Resource

    Posted May 09, 2018 02:43 AM

    Hi All,

     

    I somehow, went through the above issue, now my WebAgent is up, but I am unable to login to my base protected resource i.e. /test
    Upon checking the logs, i can see, it is AuthAccept, but AzReject or Authorization is getting failed.

     

    When i am removing the validate identity check from the above policy, it is working, but then my main sensitive data i.e. /test/transfer.html is not working, its Authentication is getting failed this time.

    Can somebody help!
    TIA



  • 5.  Re: CA SSO Re-Authenticate on Sensitive Data/ Resource

    Posted May 10, 2018 03:53 PM

    PrateekAg

     

    The problem here is, we seem to have jump 10 steps forward directly without understanding the repercussion of what a feature would do over another feature; and now we are left  retracing our steps to figure out what feature set is breaking which one.

     

    The way I would have dealt this is asking a question to CA, whether "Sensitive task as a feature is supported, if Az is disabled via ACO". We missed to ask ourselves this basic primitive question and jumped straight into the fire (delivery). Sensitive task is a different feature and Disable Az is a different feature. If I connect the dots both features have different roles to play in the Authorization phase. I am pretty sure the answer would have been "not supported". You could still confirm the same by raising a CA Support as an RFI to simply ask CA "Whether, Sensitive task as a feature is supported, if Az is disabled via ACO".

     

     

    Now besides the above discussion, from a technical perspective, here's how I would have started working on this.

    1. The first and foremost step would be to start with a basic OOB configuration working with Authentication, Authorization enabled. This is a standard OOB Integration with no changes to ACO (using default ACO parameters) and with a standard rule / policy. Make sure this is working fine.
    2. The Second step would be add Sensitive task configuration into the OOB Policy Domain / ACO configuration and see if the feature worked.
    3. If and only if the Second step succeeds, I'd now bring in "Disabling Az from ACO" and see what repercussion does this change cause to the Sensitive Tasks feature.

     

    The problem as we see here, you've jumped straight into Step-3 (Assuming it would work) and now are left with the daunting task to decipher / retrace your steps.

     

    Path forward.....

    • Raise a CA Support Case (RFI) seeking if Sensitive task as a feature is supported, if Az is disabled via ACO".
    • Raise a CA Support Case to debug any issues
    • If you need guidance, engage CA Services to guide on your solution's.