IBM Security Verify

Expand all | Collapse all

Return External User from Federation

  • 1.  Return External User from Federation

    IBM Select
    Posted Wed September 29, 2021 12:14 PM


    We have an issue where we have internal and external users accessing sites in our environment.  External users come in via federation and we had to do some trickery to make this work.  But once we get the user on a site, we try to federate the user to another site.  It works just fine for users who authenticate using forms auth.  However, it doesn't work for people who federate to us.  

    The source of the problem is that the users are internal for those use cases that work.  However the users are external for the use cases that don't work.  We get the "Could not acquire a client credential" error as a result.  Is there a way to update the mapping rule to return the user with the External EAI User header attribute?  We can't change the POC because we would break a lot.

    I also tried to set the internal user response header in the webseal.conf to both the internal and external user setting.  But the webseal doesn't like that either.

    The only other thing i can think of is somehow using an HTTP transformation and go through the webseal twice.  The second hop would basically copy the internal user header attribute into the external response header.


    Troy Burkle

  • 2.  RE: Return External User from Federation

    Posted Thu September 30, 2021 01:59 AM
    What you've said doesn't seem to be the whole story, or at least I can't quite work something out. You've said the error occurs when you are trying to perform federated SSO in the role IDP, using a session for a user that authenticated in via federated SSO as well. 

    The part that I don't get is that the "Could not acquire a client credential" error occurs when WebSEAL tries to build a new credential via EAI (including when using ISAM/ISVA federation). This normally happens when someone is *logging in* via federation (i.e. in the role of SP), not when they are already logged in and trying to perform federated SSO to another SP.

    I think further explanation is required to fully understand the use case.

    Regardless, if you are getting that type of error, one of the first things I'd do is turn on pdweb.snoop trace and capture just the flows that occur through the WebSEAL when reproducing this problem. Share that and the configuration options for [eai] and [eai-trigger-urls] from the WebSEAL configuration file, and things should become clearer as to what the issue and options are.

    Shane Weeden