<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 5/26/15 11:49 AM, Mark McCoy wrote:<br>
</div>
<blockquote cite="mid:9A65B4FB-6F6B-46D9-BD62-139A2D972C81@utsa.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>We are trying to add a check on the user’s IP address to
determine whether or not the user is coming from on or off
campus.</div>
<div><br>
</div>
<br>
<div>In a scripted attribute, I’ve tried to use the following
calls to get the user’s IP address. </div>
</blockquote>
<br>
<br>
For the record, on what type of SAML request flow do you see it not
working correctly: SAML 1 vs 2? Front-channel vs back-channel
attribute query? Everything?<br>
<br>
<br>
<blockquote cite="mid:9A65B4FB-6F6B-46D9-BD62-139A2D972C81@utsa.edu"
type="cite">
<div>Every call results in the getInboundMessageTransport()
returning a null value, which obviously causes the
getPeerAddress() call to fail. Other calls to methods contained
within the requestContext succeed (example, the getEntityId()
call works fine).</div>
</blockquote>
<br>
Well, I tested the basic SAML 2 front-channel authN request flow
case, and it worked ok for me. I just did some logging of various
bits:<br>
<br>
<tt>importPackage(Packages.org.slf4j);</tt><tt><br>
</tt><tt><br>
</tt><tt>logger = LoggerFactory.getLogger("BRENT.script-test");</tt><tt><br>
</tt><tt><br>
logger.debug("Inbound message issuer: {}",
requestContext.getInboundMessageIssuer());</tt><tt><br>
</tt><tt>logger.debug("Peer entityID: {}",
requestContext.getPeerEntityId());</tt><tt><br>
</tt><tt>logger.debug("Inbound message transport: {}",
requestContext.getInboundMessageTransport());</tt><tt><br>
</tt><tt>logger.debug("Inbound transport peer address: {}",
requestContext.getInboundMessageTransport().getPeerAddress());</tt><br>
<br>
<br>
<br>
The inbound transport was as expected an instance of the servlet
request adapter, and the peerAddress was available:<br>
<br>
<tt>17:51:54.208 - DEBUG [BRENT.script-test:-2] - Inbound message
issuer: <a class="moz-txt-link-freetext" href="https://www.test.middleware.georgetown.edu/shibboleth">https://www.test.middleware.georgetown.edu/shibboleth</a></tt><tt><br>
</tt><tt>17:51:54.211 - DEBUG [BRENT.script-test:-2] - Peer
entityID: <a class="moz-txt-link-freetext" href="https://www.test.middleware.georgetown.edu/shibboleth">https://www.test.middleware.georgetown.edu/shibboleth</a></tt><tt><br>
</tt><tt>17:51:54.212 - DEBUG [BRENT.script-test:-2] - Inbound
message transport:
org.opensaml.ws.transport.http.HttpServletRequestAdapter@4eae78e5</tt><tt><br>
</tt><tt>17:51:54.212 - DEBUG [BRENT.script-test:-2] - Inbound
transport peer address: 10.212.128.228</tt><tt><br>
</tt><br>
<br>
<br>
<blockquote cite="mid:9A65B4FB-6F6B-46D9-BD62-139A2D972C81@utsa.edu"
type="cite">
<div><br>
</div>
<blockquote style="margin:0 0 0 40px; border:none; padding:0px;">
<div>
<div>try {</div>
<div> var ipAddress =
requestContext.getInboundMessageTransport().getPeerAddress();</div>
<div>} catch (err) {</div>
<div> var ipAddress = 'unavailable'</div>
<div> logger.warn(pre + err);</div>
<div>}</div>
<div>logger.debug(pre + "ipAddress = " + ipAddress);</div>
</div>
</blockquote>
<div>
<div id="">
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
Off-hand I don't spot any typos etc there, but I'd double-check what
you actually have in the script.<br>
<br>
<br>
<br>
<blockquote cite="mid:9A65B4FB-6F6B-46D9-BD62-139A2D972C81@utsa.edu"
type="cite">
<div>
<div id="">
<div>
</div>
<div><br>
</div>
<br>
<div>Any suggestions?</div>
<br>
</div>
</div>
</blockquote>
<br>
<br>
Nothing other than just checking for typos, making sure you've
restarted after making all changes, etc. I don't think that the i<tt>nboundMessageTransport</tt>
property on the context can ever be null. That's fundamentally how
the HttpServletRequest is accessed and processed. So I think you
have something else amiss here. Maybe try copy/pasting my above
logging code directly, and see what results you get.<br>
<br>
I suppose it could be some sort of weird scripting bug we haven't
encountered yet. Actually, I note you said you're using OpenJDK
1.7.0.75. We have had reports of various weird bugs that went away
when OpenJDK was switched out for Oracle JDK ,etc. So I guess you
might try that.<br>
<br>
--Brent<br>
<br>
<br>
</body>
</html>