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.  Network restriction policy evaluation from AAC

    Posted 04/16/21 08:15 PM
    Edited by Sylvain Gilbert 04/16/21 08:17 PM

    How to implement network-based access restriction (based on ip ranges) …… but for a particular SAML2.0 Federation ?  I believe the POP method is too restrictive as I cannot easily attach it on a particular FED trigger URL, or can I ?

    I was thinking it could be possible to implement similar functionality where it would be evaluated inside a Federation SSO Access Policy … but I can't locate the information anymore. Something was available in either 10.0.1.0 or coming in 10.0.2.0 to provide visibility in the AAC module on the IP of the user in front of WebSEAL ? Along that line.

    Thanks for your help.



    ------------------------------
    Sylvain Gilbert
    ------------------------------


  • 2.  RE: Network restriction policy evaluation from AAC

    Posted 04/19/21 06:45 AM
    Hi Sylvain,

    You're right, attaching a POP for an individual federation is not that easy - that's why Access Policies were created.

    You have access to the user credential in the Access Policy and this should include the IP address of the client that was recorded at login time.

    In 10.0.1.0 there is the ability to have the IP address in the credential set based on the value of a header (e.g. X-Forwarded-For) when it's available.

    In 10.0.2.0 there is planned support for the "Proxy Protocol" which allows a front-end loadbalancer/proxy that supports this protocol to provide information such as client IP address as part of the HTTP flow.  This would influence the IP address reported in the credential.

    In the Access Policy you also have access to the request context which would include X-Forwarded-For header for the specific request.  I don't know if the client IP address (at IP layer) is available in this context or not.

    Jon.

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



  • 3.  RE: Network restriction policy evaluation from AAC

    Posted 04/19/21 06:46 AM
    Perhaps this blog can help: https://www.ibm.com/blogs/sweeden/using-federated-sso-access-policies-conditional-two-factor-authentication/

    Jon.

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



  • 4.  RE: Network restriction policy evaluation from AAC

    Posted 04/26/21 02:47 PM

    Hi Jon

    Thanks for the pointers.  Here is a summary of my findings:

     

    a) We have our Edge Network Layer pass to the Web Reverse Proxy the web client IP inside the 'x-forwarded-for' HTTP Header.


    b) The Web Reverse Proxy is also passing down to the "/isam" (Liberty AAC Runtime junction) the same HTTP Header ('x-forwarded-for') as demonstrated by the pdweb.debug snippet:

     

    2021-04-26-09:12:01.063-04:00I----- thread(13) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- PD ===> BackEnd -----------------

    Thread 13; fd 258; local 172.26.194.150:46774; remote 10.176.92.137:443

    POST /sps/authsvc?StateId=lGDPrIz6krArg7fD7ziboz71bj9G5Eq9uYS2XSsEElLHHdHkPYhHEDEfuEpT4WHBNcNaiRL2CcjuH3A3FelFfn2G6AGtm4YgvSiHn4btzHFS4TRcnWW0I1O1Y0ER2ZVo

    ...

    x-forwarded-for: 1.2.3.4, 1.2.3.4

    ...

     

    The following JS snippet inserted in an InfoMap Authentication Mechanism also demonstrates the availability of such HTTP Header ('x-forwarded-for') (ref: https://philipnye.com/2017/01/19/get-headers-and-cookies-in-javascript-infomap-mechanism/):


    // Get all headers

    var headersMap = context.get(Scope.REQUEST, "internal:authsvc:request", "headersMap");

    IDMappingExtUtils.traceString("LOGIN-MECHANISM (Policy="+policyId+") (0) -> Found headers from REQUEST: " + headersMap);

    //Get a Header

    var x_forwarded_for_header = headersMap.get("x-forwarded-for");

    if (x_forwarded_for_header != null && x_forwarded_for_header.length == 1 )

    {

        IDMappingExtUtils.traceString("LOGIN-MECHANISM (Policy="+policyId+") (0) -> Found 'x-forwarded-for' from REQUEST: " + x_forwarded_for_header[0]);

    }

     

    Yields the following:

    [4/26/21 9:59:59:929 EDT] 0002d3c4 id=00000000 om.tivoli.am.fim.trustserver.sts.utilities.IDMappingExtUtils > traceString ENTRY LOGIN-MECHANISM (Policy=ifc-unified-username-login) (0) -> Found 'x-forwarded-for' from REQUEST: 1.2.3.4, 1.2.3.4

     

    c) Now let's move to the Access Policy code concept which is similar but slightly different than in an InfoMap Authentication Mechanism (ref: https://www.ibm.com/docs/en/sva/9.0.5?topic=development-request-context-example-access-policy). The following code in inserted right at the beginning of the Access Policy evaluation (before deny vs allow decision are taken):


    var request = context.getRequest();

    var headerNames = request.getHeaderNames();

    for (var it = headerNames.iterator(); it.hasNext();)

    {

        var headerName = it.next();

        var headerValue = request.getHeader(headerName);

        IDMappingExtUtils.traceString("Access Policy (SOMEPOLICY) -> Found '"+ headerName + "' from REQUEST: " + headerValue);

    }

     

    Which yield the following output:

     

    ...
    [4/26/21 14:08:58:792 EDT] 0002e421 id=00000000 om.tivoli.am.fim.trustserver.sts.utilities.IDMappingExtUtils > traceString ENTRY Access Policy (SOMEPOLICY) -> Found 'x-forwarded-for' from REQUEST: 1.2.3.4, 1.2.3.4

    [4/26/21 14:08:58:792 EDT] 0002e421 id=00000000 om.tivoli.am.fim.trustserver.sts.utilities.IDMappingExtUtils < traceString RETURN
    ...

    This is tested solely with 10.0.1.0 and it does seem I am not requiring additional new stuff to appear in 10.0.2.0.

    Now my only question remaining: Now that I demonstrated having visibility over the x-forwarded-for HTTP header, I could of course implement our technical requirements as-is. But just wondering if there would be other capabilities in the appliance that are meant to write such policy once we have confirmed visibility over a special attribute like x-forwarded-for ? Based on a mix of Risk Profiles, Attributes, .... ?

    Thanks



    ------------------------------
    Sylvain Gilbert
    ------------------------------

    Original Message


  • 5.  RE: Network restriction policy evaluation from AAC

    Posted 04/29/21 07:32 AM
    Hi Sylvain,

    Thanks for the detailed report on where you were able to read the X-Forwarded-For header.

    I'm not exactly sure what you're asking in your final question but let me see if I can say a few things that might help:

    As I mentioned before, in 10.0.1.0 there is a configuration option so that the IP address stored in the user's credential (and therefore used by POP and used to populate the ipaddress attribute in Context-based access) is taken from X-Forwarded-For header instead of the physical source IP.  That is probably the easiest way to get the "real" client IP address in all cases.  This feature was added specifically to support cases where you have an Edge device which would otherwise always be the physical source IP reported in the credential.

    If (for some reason) you want to do without the option above, I think you could also get the X-Forwarded-For header into an attribute for context-based access.  You would need to create an attribute in AAC to represent this and then add configuration to Reverse Proxy to have it populate that attribute from HTTP header when sending authorization requests to AAC.

    If you needed to process the header (so that only the first/last entry in the header is reported) I think you could do that by defining another attribute that is provided by a JavaScript PIP.... the JavaScript would read the attribute populated by the Reverse Proxy and return the formatted version.  You could do other logic in this PIP and just return a permit/deny decision instead (if you wanted some complex logic based on the IP address).

    Jon.

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

    Original Message


  • 6.  RE: Network restriction policy evaluation from AAC

    Posted 04/29/21 09:21 AM

    Hi Jon

     

    I will clarify further the use case. During our exploration, we realized that we don't need to authenticate the user before performing the evaluation of his/her network origin as the requirement is not even to trigger Step-Up but instead to just Deny access from certain network zones. Which made me switch from inspecting for the origin IP in the user credential context to looking instead in the request context in the access policy.

    Although I have now validated that I could obtained the x-forwarded-for IP, I was still interested in learning about that V10.0.1.0 capability. But I realized that since I had already access to the x-forwarded-for header on the back-end junction, then how come that all this happened ? I verified in the WRP configuration and we have no specific settings for the x-forwarded-for header, so my guess is that if it is passed by the edge device to the wrp which in turn it just forwards it to the junction automatically, like any other http header. It just happens here in our case is that we don't need any header name re-mapping (x-forwarded-for mapped to client-ip for instance).

    But now, I am confident that I can fulfill the security requirements we were given using the Access Policy with some JS coding approach.

    I also understand there is this entire CBA feature I need to spend time learning to implement similar (or richer) requirements in the feature in a different manner. I think this is why you may have not understood by "final" question. Nevertheless, you succeeded in decrypting my thoughts on the subject. And so you confirmed me that yes, there "is another way", as it is often the case with ISVA (-;



    ------------------------------
    Sylvain Gilbert
    ------------------------------

    Original Message


Related Content