IBM Security Verify

 View Only
  • 1.  STS validation module chain : how to access request headers ?

    IBM Champion
    Posted Tue June 30, 2020 10:56 AM
    Hi everybody,
    In a PSD2 context, we have a reverse proxy (for api exposition) that is executing a STS module chain for each incoming request.
    This is configurated on webseal's config as follow:
    # other less important stanzas removed 
    [oauth]
    oauth-auth = https
    default-fed-id = urn:jwt:webseal
    cluster-name = oauth-cluster
    
    [tfim-cluster:oauth-cluster]
    server = 9,https://localhost:443/TrustServerWST13/services/RequestSecurityToken
    
    
    
    # This stanza was configurated hoping to find those additional headers once in the STS chain
    [azn-decision-info]
    HTTP_HOST_HEADER = header:host
    HTTP_XGTID_HEADER = header:x-global-transaction-id
    HTTP_LHPSUTOKEN_HEADER = header:lh-psu-token
    HTTP_LHJWT_HEADER = header:jwt​

    For each incoming request the STS chain with the id urn:jwt:webseal is correctly executed.
    That STS Chain is made of a single MAP step, with an associated mapping rule.

    ​Unfortunately, once in the mapping rule of the chain, I have found no way to access any of the http headers of the initial request (even after adding those headers in azn-decision-info)


    How can I configure webseal so that those additional headers are sent in the request to the STS and could be used for deciding the correct identity for the initial request ?

    ------------------------------
    André Leruitte
    ------------------------------


  • 2.  RE: STS validation module chain : how to access request headers ?

    Posted Tue June 30, 2020 12:12 PM
    Hello André,

    The azn-decision-info is only relevant when calling the AAC context-based authorization function.

    It may be that what you are attempting is not possible.  The OAuth callout is specifically for validating the received token - I don't think it takes any account of anything else in the received request.

    There is an "Advanced Configuration" option sps.httpRequestClaims.enabled which passes additional request claims from SPS to STS (in the STSUU object) but I'm not that hopeful it will work in the case of OAuth validation (because that doesn't use the SPS).

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 3.  RE: STS validation module chain : how to access request headers ?

    IBM Champion
    Posted Tue June 30, 2020 12:27 PM
    Edited by André Leruitte Tue June 30, 2020 12:27 PM
    Thanks for your reply Jon, I was afraid of that answer.

    Do you have any other idea on how we could implement this validation of the incoming request ?
    Could implementing it in a OAuth policy instead be a solution ? (and using the "resource" request type in the POSTToken mapping rule for doing the advanced validation)


    ------------------------------
    André Leruitte
    ------------------------------



  • 4.  RE: STS validation module chain : how to access request headers ?

    IBM Champion
    Posted Mon July 13, 2020 05:48 AM
    Hi everybody,
    We are still blocked on this issue and have not found any satisfying solution.

    While waiting (and hoping) for a clean solution, we had to implement a workaround on the Datapower that is in front of our ISAM's. The workaround consist of :
    - Datapower : concatenate all the http headers needed in the Authorization header
    - ISAM - STS transformation : check if Authorization header contains the separator character. If it does, split all the values so the individual header values are available

    This workaround is functionnal but it isn't clean in any way.

    We really hope that a clean solution will be suggested by someone, or that someone can point us to another solution (is ISAM the correct middleware for doing this kind of validation of incoming requests?)

    Regards

    ------------------------------
    André Leruitte
    ------------------------------



  • 5.  RE: STS validation module chain : how to access request headers ?

    Posted Tue July 14, 2020 07:19 AM
    Hi André,

    I confirmed with development that the only headers which are forwarded in the token validation request in oauth-auth are the Authorization header (whatever is after Bearer label) and the Host header.  There is no configuration available to pass additional headers.

    So, your workaround is the only solution available today - I understand your feeling that it is "not clean".  The only change I could suggest would be to perform the header modification in an HTTP Transformation rule in Reverse Proxy to remove the dependency on DataPower.  But if you have DataPower in the flow already and it is easier to do there then it's the same result.

    The ability to get additional request context in the token validation request does sound useful.  I would suggest that you create an RFE for this.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 6.  RE: STS validation module chain : how to access request headers ?

    Posted Tue July 14, 2020 10:36 AM
    Hi Jon and André,

    As Jon mentioned, http headers from STS soap request are not passed to the STS in current ISAM,  I agree this could be a RFE, with this feature, the http headers claims could be available for use in STS identity mapping, and it's a useful feature.

    Best Regards

    Chen Yongming

    ------------------------------
    Yongming Chen
    ------------------------------



  • 7.  RE: STS validation module chain : how to access request headers ?

    IBM Champion
    Posted Thu July 16, 2020 01:51 PM
    @Jon Harry thank you for taking the time to ask if there wasn't any possible workaround.

    Thank you both for your suggestion of adding an RFE.
    I just created it and tried to make it public (I don't know if security related RFE's can now be public) : http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=144017




    ------------------------------
    André Leruitte
    ------------------------------