Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Location Assertions           Ian A.Young  TAG meeting, January 19th, 2012
Problem Statement•   Initial use case is from Schools sector•   SP business model:    •   Primary market is individual hom...
Solution Components• Attribute profile • Which attributes? • Which values?• Implementation • Independent of attribute profile
Attribute       Considerations• User may be “on” multiple networks at  once: attribute must be multi-value• Simple values ...
eduPersonEntitlement• Existing core attribute (TRP §7.3)• Anyone can define “on network X” values• We could curate agreed v...
ukfNetworkLocation•   New subsidiary attribute (TRP §7.3)•   We’d have to define the attribute•   Fixed vocabulary:    •   ...
Initial Implementation          • Operator will commission implementation          • For latest Shibboleth 2.X IdP only   ...
Initial Implementation•   Will work for either attribute profile•   Configuration:    •   Attribute name (urn:oid:...)    • ...
Shibboleth V3• Will commission update of implementation  for Shibboleth V3.0 APIs• Implementation will then be donated to ...
Security Note• Known issue with back-channel attribute  queries• http://shibboleth.internet2.edu/secadv/  secadv_20110718....
Upcoming SlideShare
Loading in …5
×

Location assertions 1

1,593 views

Published on

Presentation to the UK federation TAG by Ian Young

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Location assertions 1

  1. 1. Location Assertions Ian A.Young TAG meeting, January 19th, 2012
  2. 2. Problem Statement• Initial use case is from Schools sector• SP business model: • Primary market is individual home users • Secondary sales to schools for pupils at school: “on network” • Need to distinguish these cases • Want to move from IP recognition at SP to IdP asserting network location
  3. 3. Solution Components• Attribute profile • Which attributes? • Which values?• Implementation • Independent of attribute profile
  4. 4. Attribute Considerations• User may be “on” multiple networks at once: attribute must be multi-value• Simple values imply central registry; URI values allow anyone to extend• Existing attribute is easier to configure in some cases, but isn’t use case specific• New subsidiary attribute would be our first!
  5. 5. eduPersonEntitlement• Existing core attribute (TRP §7.3)• Anyone can define “on network X” values• We could curate agreed values for the NEN use cases• Can be tricky to merge ePE values from multiple sources within the IdP
  6. 6. ukfNetworkLocation• New subsidiary attribute (TRP §7.3)• We’d have to define the attribute• Fixed vocabulary: • slightly easier to use • needs central registry that we’d have to administer• Or URI values: • No need for central registry, but again we could curate common values.
  7. 7. Initial Implementation • Operator will commission implementation • For latest Shibboleth 2.X IdP only • not simpleSAMLphp, not Shib 1.3 • Shipped as an extension • extended UsernamePassword login handler • either a data connector or attribute definitionMost Schools IdPs (14) are Shibboleth 2.somethingSome may not be up to date, but probably close enoughSome (3) are simpleSAMLphp
  8. 8. Initial Implementation• Will work for either attribute profile• Configuration: • Attribute name (urn:oid:...) • Attribute value (http://.../) • Set of IPv4 and IPv6 CIDR blocks • 129.215.135.0/24 • 2001:630::/48
  9. 9. Shibboleth V3• Will commission update of implementation for Shibboleth V3.0 APIs• Implementation will then be donated to Shibboleth project• Deploying an extension no longer required
  10. 10. Security Note• Known issue with back-channel attribute queries• http://shibboleth.internet2.edu/secadv/ secadv_20110718.txt• Bottom line: you can attack this if you’re sly. We’re assuming this edge case isn’t important.

×