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.

  • No labels

2 Comments

  1. 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?

    the IdP needs to release the IP adress of the user as attributes

    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 the library-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.)

    1. 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:

      • One IDP for walk-in users for multiple libraries. These libraries might not be large enough to operate their own IDP
      • An admin interface & LDAP server to store IP address - entitlement combinations
      • The IDP would then retrieve the appropriate entitlements as attributes, using the IP-attribute as a query parameter in LDAP

      I can't comment on the work done by UKf and the Belgrade talk.