Problem Statement• Original requirement from the Schools Sector;• SP Business Case: – Primary market is individual home users; – Secondary sales to schools for pupils ‘on network’;• Need to distinguish these cases;• Desire to move from SP recognising IP to IdP asserting location.
Why not IP authentication?• Often not granular enough;• Easy to ‘fake’;• Difficult to maintain accurately;• Prone to keying errors;• Low tech implementations.
Location Assertion Extension• Extension to Shibboleth;• Downloadable and implementable now;(https://github.com/ukf/ua-attribute-idp- ext);• Creates attributes at the time of authentication based on IP address of the user agent;• SP can make decisions based on known location as well as other assertions.
What Does it Look Like?New Subsidiary attribute and use of eduPersonEntitlementresolver:DataConnector id=”userAgentAttributes”xsi:type=”uadc:UserAgentMappedAttributes”uadc:Mapping cidrBlock=”184.108.40.206/16″attributeId=”userAgent”attributeValue=”http://iay.org.uk/networks/zenInternet”/uadc:Mapping cidrBlock=”220.127.116.11/14″attributeId=”userAgent”attributeValue=”http://iay.org.uk/networks/zenInternet”/uadc:Mapping cidrBlock=”192.168.117.19/32″attributeId=”eduPersonEntitlement”attributeValue=”http://iay.org.uk/entitlements/kestrel”/
Solving Walk-in?• Allows Walk-in with BYOD;• Easy to provision guest accounts that don’t work outside the institutional boundary;• Able to configure walk-in at a granular level for SPs that don’t allow.BUT…
Service Provider ImplementationPublishers have to actually consume and react to the attributes being passed.
More informationBlog post:• http://access.jiscinvolve.org/wp/wayrn2/The code:• https://github.com/ukf/ua-attribute-idp-ext