IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  Always try kerberos authentication

    Posted 04/08/21 09:58 AM
    Hi community,
     
    wie have developed a complext custom authentication policy that should be triggered for every users exept of those, who have logged-in using kerberos. That means, that the policy is responsible to authenticate the user if they are not already authenticated with kerberos.

    The problem is, that we need to let unathenticated user to call the protected resouce in order to let the AAC policy trigger (via POP), but if the path does not require authentication then kerberos authentication is not been triggered neither. It is possible to call the policy direct, but the path does not require authentication and kerberos would be not triggereg neither.

    Is it possible to make WebSEAL to always try to authenticate the user with kerberos? Or is there any ideas how we kann force kerberos authentication before AAC Policy is triggered but still let unathenticated users reach the policy?

    ------------------------------
    Best Regards
    Ivan Yartsev
    ------------------------------


  • 2.  RE: Always try kerberos authentication

    Posted 04/09/21 02:27 AM
    Hi,
    Kerberos authentication in the description is probably Windows desktop single sign-on you are referring to and not Kerberos constrained delegation (KCD) , which is a different mechanism for SSO to the backend. (see https://www.ibm.com/docs/en/sva/10.0.0?topic=methods-windows-desktop-single-sign).
    One option is to configure WebSEAL for authentication levels (https://www.ibm.com/docs/en/sva/9.0.7?topic=levels-using-multiple-authentication) .
    In the AAC module create a Access Control Policy  .Create a conditional rule where you can use the AuthenticationLevel, Mechanism, Method as criteria for permit or deny decision and attach it to the resources.
    You will have to test for a couple of side-effects due to Windows dekstop SSO .
    Hope this helps
    Kind regards
    Serge Vereecke

    ------------------------------
    Serge Vereecke
    ------------------------------



  • 3.  RE: Always try kerberos authentication

    Posted 04/16/21 09:30 AM
    Hi,

    Thank you fo your answer. Yes, I was reffering to Windows desktop SSO.
    The resource is already Protected with a conditional policy. The Problem is:

    The resource does not require login (ACL unauthenticated Tr) that means that AAC policy is triggered to perform user authentication. Since unauthenticated access is allowed, the WebSEAL passes the request directly without performing Windows deskop SSO login operation (401 Unauthorized with  WWW-Authenticate: Negotiate header). In this case the condition
    if authenticationMethod has member "kerberosv5"
    has no sence, since no one has this method.

    If I set ACL unauthenticated to  "T", then internal users, who cann be logged on via kerberos could get access to the resource, but those who couldn't would get login page from WebSEAL, but the authentication schould be performed in this case not by WebSEAL, but by AAC Policy. So it doesn't work either.

    One solution is to create a page with redirect to the target resource and place it to the junction root (for example with the name login.html) and management root as login.html.
    User schould call then https://ws/login.html
    The page should be protected with default ACL.
    If a user can be logged in via kerberos, then he will be redirected to the target resource and the attached policy can recognise, that the user has kerberosv5 and permits the access.
    If a user cannot be logged in automatically via kerberos, then login.html from management root will be loaded by the browser. Since that page has the redirect to the target resource, the user will be redirected to that resource and can authenticate himself by AAC Policy.

    That solution works, but may be there are other ideas how it can be done better.




    ​​​​

    ------------------------------
    Ivan Yartsev
    ------------------------------

    Original Message


Related Content