1. Multi-Organizational Authorization Services RL “Bob” Morgan, University of Washington Internet2/Educause Advanced CAMP Boulder, Colorado July 2003

2. Copyright RL ‘Bob’ Morgan, 2003. This work is the intellectual property of the author. Permission is granted for this material to be shared for non- commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

3. Topics External users in your enterprise IdM and apps Consortia and Identity The multi-attribute-provider problem

4. External users in your enterprise Yet another external population every day... all doctors in the state collaborative course hosted by your LMS grant collaborators Just give 'em campus netids? feed problems, identifying info, etc; authorization granularity;... ultimately doesn't scale... So, federate, of course with Shib, or accept Passport, or PKI, or whatever not the whole story...

5. External users and IdM App Your University Some Origin IdM/Authz Authn Attribute Authority IDs?

6. Privacy and IDs Privacy protection: not using a single permanent ID in some cases (eg licensed content), simple group-based attribute may be all that's needed for access this is why “entitlement” is attractive but permanent target-specific identifier may still be useful, e.g. for personalization non-shared target-specific IDs make combining authorizations difficult put burden on user to gather entitlements?

7. Integration of externals In most cases, external users coexist with internal users on same app system but that app relies on your IdM for more than just netid external user's origin may supply authz attributes... but if the app relies on user data in IdM... implies external user in your IdM, with their external id Provisioning issues does external user get registry-id? does remote site supply one? how do you get notification of external-id change? are external entries mixed with your existing user entries?

8. Integration of externals, more Remote user entries in your IdM? every institutional IdM is a view of the whole world, just contains “more authoritative” data about internal users Stanford IdM is authoritative about Stanford user's netid UW IdM is authoritative about Stanford user's use of UW app ultimately sources of authority are distributed... Existing internal attributes now need scope... app may have policy: if “student” then X –does it mean “if student anywhere” or “if student@foo.edu”

9. State-wide K-20 service authz Washington plans access to learning services for all students, state-wide who is a student's identity provider? (ie, where are they from?) UW, which supplies infrastructure? (user@washington.edu) the learning-services project? (user@learningcommons.org) their school district? (user@seattleschools.org, eg) their school? (user@forks-high.wa.us)

10. Multi-attribute authorities App Target Origin Attr Authority Authn Attribute Authority

11. the multi-attribute-provider problem aka “the IEEE problem” foo.edu user at info-provider.com site –can get to some resources as a Foo U member –can get to other resources as IEEE member –wants to do both at once, with foo.edu-based authentication approaches: –Foo U IdM/AA has “ieee-member” attribute, supplies it, info-provider accepts it –info-provider redirects user to IEEE site, user gets assertion, returns –info-provider calls IEEE site directly to get member info –info-provider provisioned with ieee-member attribute for that user constraints: user experience, privacy, forgery, identity mapping

12. Conclusion If they're “users” they're probably “internal” There will be many attribute providers Application architecture essential