Hello,
we do this using a scripted attribute. If the specific combination is
not permitted we return an invalid value. It's not perfect because the
user doesn't get informed why it doesn't work, but educating the user
in advance that it won't work was enough for us to make it acceptable.
The attribute resolver looks like this
<resolver:AttributeDefinition xsi:type="Script" id="email"
xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="mail">
<resolver:Dependency ref="theLDAP" />
<resolver:AttributeEncoder xsi:type="SAML2StringNameID"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
name="email" />
<ScriptFile>/opt/shibboleth-idp/conf/email.js</ScriptFile>
</resolver:AttributeDefinition>
And in the script you could put something like this:
importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
importPackage(Packages.org.slf4j);
logger = LoggerFactory.getLogger("edu.internet2.middleware.shibboleth.resolver.Script.scriptTest");
logger.info("This is a request for " +
requestContext.getRelyingPartyConfiguration().getRelyingPartyId());
var emailAdress ;
var ipAddress = requestContext.getInboundMessageTransport().getPeerAddress() ;
if ( ( ipAddress.match("10\\..*") &&
requestContext.getRelyingPartyConfiguration().getRelyingPartyId() ==
"somerelyingparty" ) ||
requestContext.getRelyingPartyConfiguration().getRelyingPartyId() !=
"somerelyingparty" ) {
emailAdress = mail.getValues().get(0);
} else {
emailAdress = "***@nowhere";
}
email = new BasicAttribute("email");
email.getValues().add(emailAdress);
logger.info("Provided email address " +email.getValues().get(0));
ps.: Edited in gmail, so there may be small typo's or syntax errors,
but the idea is there.
Kind Regards,
JAN KEIRSE
Thank you for the hint Ian, but IdPAuthIP is not the solution because the SP
expects to receive attributes so username/password authentication is a
must. Firewalling is not an option because other SPs dont have this IP
restriction.
We need - prior to authentication - a check done by the IdP on browser IP
and SP being accessed.
Any help here would be greatly appreciated.
Stefano
Post by Ian RifkinHi Stefano,
Post by Stefano Zanmarchiwe need to limit access to a given SP to users within a given IP range.
We can only work on the IdP side.
I'm not an expert, so maybe someone else can chime in, but I think it
would depend on your configuration. You can put IP restrictions in webserver
and firewall software, but you can't do that if you use the IdP for other
SPs that don't have this IP restriction. If you have a custom auth piece it
looks like you can read about
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthIP. Or perhaps
attempt something more fancy/custom.
Taking a step back, how do you currently do authentication? And what does
the SP expect to receive back from you (do they do any authorization or does
the SP just assume if they get a reply they are good?).
Regards,
Ian
--
To unsubscribe from this list send an email to
--
To unsubscribe from this list send an email to
--
**** DISCLAIMER ****
http://www.tvh.com/newen2/emaildisclaimer/default.html
"This message is delivered to all addressees subject to the conditions
set forth in the attached disclaimer, which is an integral part of this
message."
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org