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:
Sent: Mon April 19, 2021 06:46 AM
From: Jon Harry
Subject: Network restriction policy evaluation from AAC
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
Original Message:
Sent: Fri April 16, 2021 08:15 PM
From: Sylvain Gilbert
Subject: Network restriction policy evaluation from AAC
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
------------------------------