IBM Security Verify

 View Only
Expand all | Collapse all

OAuth for External Users

  • 1.  OAuth for External Users

    Posted Fri April 24, 2020 12:42 AM
    Edited by Piyush Agrawal Fri April 24, 2020 12:51 AM
    I am trying to setup api-protection on our Reverse Proxy on ISAM(9.0.6). EAI is configured which creats session for internal as well as external users.
    Response Headers added by EAI java application:
    1. Common Headers:
      • am-eai-auth-level, am-eai-redir-urlam-eai-xattrs(Name, systemid,tagvalues)
    2. Internal User:
      • am-eai-user-id
    3. External User:
      • am-eai-ext-user-id, am-eai-ext-user-groups

    Demo app is enabled as explained on MMFA cookbook and junction is created with iv-creds.
    Now I am trying to consume resource like https://portal/app/mobile-demo/diag/rest.jsp with access_token received from /token endpoint.
    It works for Internal User but fails for External User and I am redirected to /eai/login for authentication. when I try https://portal/mga/sps/oauth/oauth20/userinfo for same user that it works.

    RSTR in Trace log  has response:

    authorized = TRUE and

    username = EXTUSER_01

    Secure Federation - Global Settings - Point of Contact has "Non-Access Manager, Access Manager Groups and extened attributes" selected

    oauth-auth = https

    default-fed-id = https://localhost/sps/oauth/oauth20

    user-identity-attribute = username

    #external-user-identity-attribute = 

    I also read 
    Allowing external users to perform OAuth authentication
    and tried external-user-identity-attribute =  am-eai-ext-user-id  but that also didn't worked  

    Piyush Agrawal

  • 2.  RE: OAuth for External Users

    Posted Fri April 24, 2020 07:11 AM
    Hi Piyush,

    When the Reverse Proxy receives an OAuth Access Token, it passes this to the AAC Runtime for validation.  It is the attributes in the token returned from this call (an STSUUser object if I remember correctly) which are being referred to in the OAuth configuration stanza.  Nothing to do with EAI HTTP headers in this case.

    By default, the AAC validation always returns the username in the "username" attribute which means WebSEAL consumes it as an internal user (as a result of user-identity-attribute = username).  In order for WebSEAL to treat the user as an external user, you must map the external-user-identity-attribute to a different attribute name and then modify the post-token mapping rule for the OAuth definition to return this attribute name (instead of username) when returning an external user.

    As a simple fix (without modifying post-token mapping rule) you can have WebSEAL treat ALL OAuth users as external users by setting:

    user-identity-attribute = dummy
    external-user-identity-attribute = username

    In this case though, internal user group membership will not be reflected in the credential.

    It's also worth noting that it is currently not possible to assert group memberships for external users during OAuth Access Token processing.

    I hope this helps you to understand the current capabilities.


    Jon Harry
    Consulting IT Security Specialist