As part of the Libraries walk-in-user pilot-pilot the Shibboleth IdP needs to release the IP adress of the user as attributes.
Download of source code as maven project:
daasi-extensions-ua.tar.gz
The extensions "user agent" is a Shibboleth data connector that provides the IP address of the user as attributes in 3 formats: IP4, IP6 or as a number. The Shibboleth
IP authentication handler is required for this data connector to work.
To deploy the connector, copy the JAR file in edit-webapp/WEB-INF/lib, re-build idp and restart tomcat.
The attribute-resolver.xml must be configured properly as the example below:
<resolver:AttributeResolver
...
xmlns:daasidc="urn:de:daasi:shibboleth:idp3:resolver:dc"
xsi:schemaLocation="...
urn:de:daasi:shibboleth:idp3:resolver:dc classpath:/schema/shibboleth-attribute-resolver-daasi-dc.xsd">
...
<resolver:DataConnector id="userAgentIpAddressDataConnector" xsi:type="daasidc:UserAgentIpAddressDataConnector" xmlns="urn:de:daasi:shibboleth:idp3:resolver:dc"
userAgentAddressIPV4AttributeName="userAgentAddressIPV4"
userAgentAddressIPV4AsLongAttributeName="userAgentAddressIPV4AsLong"
userAgentAddressIPV6AttributeName="userAgentAddressIPV6"
/>
<!-- Example Attribute Definition -->
<resolver:AttributeDefinition xsi:type="ad:Simple" id="userAgentAddressIPV4" sourceAttributeID="userAgentAddressIPV4">
<resolver:Dependency ref="userAgentIpAddressDataConnector" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String" name="http://daasi.de/userAgentAddressIPV4" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="http://daasi.de/userAgentAddressIPV4" friendlyName="userAgentAddressIPV4" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition xsi:type="ad:Simple" id="userAgentAddressIPV4AsLong" sourceAttributeID="userAgentAddressIPV4AsLong">
<resolver:Dependency ref="userAgentIpAddressDataConnector" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String" name="http://daasi.de/userAgentAddressIPV4AsLong" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="http://daasi.de/userAgentAddressIPV4AsLong" friendlyName="userAgentAddressIPV4AsLong" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition xsi:type="ad:Simple" id="userAgentAddressIPV6" sourceAttributeID="userAgentAddressIPV6">
<resolver:Dependency ref="userAgentIpAddressDataConnector" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String" name="http://daasi.de/userAgentAddressIPV6" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="http://daasi.de/userAgentAddressIPV6" friendlyName="userAgentAddressIPV6" />
</resolver:AttributeDefinition>
</resolver:AttributeResolver>
Additionally, the attribute needs to be added to the appopriate attribute-filter.
2 Comments
Peter Brand
How does the code developed by DAASI referenced above relate to earlier work done by the UKf?
Is that a resurfacing of the old topic discussed in Location, location, location - Belgrade 2012?
There's no reasoning provided above why that may be necessary (unless it's the old topic mentioned above) – the IDP evaluates the HTTP client's IP address and should only need to send along the
common-lib-terms
eduPersonEntitlement attribute value plus thelibrary-walk-in
eduPersonScopedAffiliation attribute value, but not the IP-address itself. That allows the SP to determine access based on standard attributes without having to keep managing a local list of authorised IP ranges (which most often is inaccurate or wrong, I read somewhere but can't find a reference.)David Hübner
Hi Peter Brand,
I'm not 100% aware of the contents of the pilot, but from what I understand, these IP-attributes were never meant to be released to services. In fact, I don't think they should have attribute encoders at all.
The scope of this PoC was essentially:
I can't comment on the work done by UKf and the Belgrade talk.