Provisioning and Relaying: The Integration Story

1. Provisioning and Relaying:The Integration Story http://arch.doit.wisc.edu/keith/camp/ provrel-050628-01.ppt Keith Hazelton (hazelton@doit.wisc.edu) Sr. IT Architect, University of Wisconsin-Madison Internet2 MACE CAMP Integration, Denver, June 28, 2005

2. Shibboleth v 1.2.1a Integration Overview • Shibboleth Introduction (The Relay tool from NMI / Internet2 / MACE) • Identity Provider (Origin) Deployment, Integration • Authentication/Identifier Assertion Phase Components & Dependencies • Identity Attribute Assertion Phase • Service Provider (Target) Deployment, Integration • Two scenarios for each: • Shib “classic” e-Lib: accessing licensed resources • Shib federation across a state system: shared services • The craft of federation 2

3. Basic IAM functions mapped to theNMI / MACE components Apps / Resources Enterprise Directory AuthN Systems of Record AuthN Log Reflect Provision Join WebISO Credential AuthZ Mng. Affil. Mng. Priv. Relay Log Grouper Signet Shibboleth 3

4. Basic IAM functions mapped to theNMI / MACE components Apps / Resources Enterprise Directory AuthN Systems of Record AuthN Log Reflect Provision Join WebISO Credential AuthZ Mng. Affil. Mng. Priv. Deliver Log Grouper Signet Shibboleth 4

5. Basic IAM functions mapped to theNMI / MACE components Apps / Resources Enterprise Directory AuthN Systems of Record AuthN Log Reflect Provision Join WebISO Credential AuthZ Mng. Affil. Mng. Priv. Relay Log Grouper Signet Shibboleth 5

6. Alternatives to IP Address Based Access Restriction • User-based access restriction • Each service provider manages credentials for all of its users • One big credential database of all users used by all service providers • Each user has a “home organization” whose credential database can, by magic, be used by each service provider • ??? 6

7. Federated Identities • “Federated identities” is option C on previous slide • A hierarchical approach to decompose the problem into manageable pieces • Analogous to the problem that IAM addresses, and rests upon IAM infrastructure • “Federating technology” is the “magic” part of option C • “Identity federation” (noun) is a set of service providers, identity providers, and other context in which the magic happens 7

8. SAML implementations Security Assertion Markup Language Shibboleth Bodington/Guanxi AthensIM SourceID SAMUEL MS ADFS Other proprietary Liberty Identity Federation implementations SourceID Lasso Proprietary Others MS Inter-Forest Trust Federating Technologies 8

9. Shibboleth Athenticate at home org Authorize at resource without knowing user’s identity 9

10. Swiss Research/Education Network Demo • http://www.switch.ch/aai/demo/ 10

11. Shibboleth Underpinnings • Elements of shibboleth infrastructure must identify and authenticate each other • Home org or Identity Provider (IdP) pieces • Resource or Service Provider (SP) pieces • Attribute assertions about authenticated principals are sent from IdPs to SPs • For it all to work, IdPs and SPs must agree about which attributes and values are tossed around, and their semantics 11

12. Federation Value Proposition • Set of cooperating IdPs and SPs forms a community needing agreement on: • Trust Fabric • X.509 certs • IdP and SP identifiers & other metadata • Community standard for attribute semantics • Community standards for IdP and SP operational practices • Strength of authentication • Confidentiality • For N IdPs and M SPs, which is easier? • N*M agreements • N+M agreements 12

13. Federations … • Might support trust fabric maintenance • Operate a metadata distribution service • Might be the locus for attribute standards • Might be the locus for “minimum but sufficient” IdP and SP operational practice standards • Are not a party to the transactions between IdPs and SPs • Are not involved with entitling access to resources 13

14. REF Cluster InQueue (a starting point) Other clusters Other potential US R+E feds Other national nets SWITCH InCommon NSDL The Shib Research Club State of Penn Fin Aid Assoc The Research and EducationFederation Space Indiana Slippery slope - Med Centers, etc 14

15. Shib Identity Provider / (Origin) Ident. Provider (wasabi) WAYF “HS” Service Provider (gari) Browser User Attribute Authority Apache (1.3 or 2.0) / Tomcat Web server / Servlet container Inspired by SWITCH (Swiss REN) HTTP://www.switch.ch/aai/demo/ 15

16. Identity Provider / (Origin): AuthN, Identifier Campus WebISO Identity Provider (wasabi) “HS” Attribute Authority Apache (1.3 or 2.0) / Tomcat Web server / Servlet container 16

17. WebISO requirements from Shib Campus WebISO • WebISO can authenticate a set of users based on locally issued/registered credentials • Open source WebISO package, PubCookie,mentioned in “Origin” Deployment Guide. • For details & download, see http://middleware.internet2.edu/webiso/ 17

18. WebISO alternatives Campus WebISO • But end-user PKI certs work fine, too (configurable filter) • And there are ways to support multiple AuthN methods with failover • “UW-Madison 2” InQueue IdP runs this configuration • End entity certificate with failover to LDAP basic auth. • See wasabiHttpd.conf, lines 1017 et seq. 18

19. Shib assumes Identity and Access Management (IAM) Services Meta- Directory Processes Registry Student System of Record Campus WebISO Human Resources System of Record LDAP Directory Other Systems of Record Enterprise Directory 19

20. Identity Provider Middleware Campus WebISO wasabi Enterprise Directory “HS” Attribute Authority Apache (1.3 or 2.0) / Tomcat Web server / Servlet container 20

21. Identity Provider / (Origin) Ident. Provider (wasabi) “HS” Service Provider (gari) Browser User Attribute Authority Apache (1.3 or 2.0) / Tomcat Web server / Servlet container 21

22. Identity Provider / (Origin)Attribute Assertion Phase Ident. Provider “HS” Service Provider Browser User Attribute Authority Apache (1.3 or 2.0) / Tomcat Web server / Servlet container 22

23. Identity Provider Middleware Campus WebISO Enterprise Directory “HS” Attribute Authority Apache (1.3 or 2.0) / Tomcat Web server / Servlet container 23

24. Attribute Authority (AA) <–> Ent. Directory • Shib AA Deployment Issues: • Configure AA to connect to Ent. Directory • Data connectors can be JNDI-based, JDBC-based (xml-configurable) or custom user plug-ins • Map Directory attributes to SAML attributes 24

25. Attribute Authority (AA) <–> Ent. Directory • Fragment of ..conf/origin.xml 25

26. Attribute Authority (AA) <–> Ent. Directory • Resolver links named attributes to specific data connectors: 26

27. Attribute Authority (AA) <–> Ent. Directory • …and specifies connector (here JNDI LDAP): 27

28. Attribute Authority (AA) <–> Ent. Directory • …and specifies connector (here JDBC SQL): 28

29. Attribute Authority (AA) <–> Ent. Directory • Shib AA Deployment Issues, cont.: • Comply with Attribute Release Policy (ARP) in determining which service providers get which attributes • Federation rules are given • Bilateral or Community of Interest rules need to be worked out & agreed to 29

30. Attribute Authority (AA) <–> Ent. Directory • Ah, yes, data access policy • This may drag stakeholders kicking & screaming into the room to confront policy • How you manage this will be key to successful deployment • The “DON’T PANIC” in big friendly letters on the InCommon Book may help 30

31. Attribute Authority (AA) <–> Ent. Directory • Shib can transport any attribute--it’s up to sender and receiver to agree on its semantics • “Simple matter of configuration” • Some of the newer attributes • eduPersonTargetedID if you want a persistent identifier, but one that is specific to a given Identity Provider-Service Provider pair • Course-related attributes. URN-based identifier guideline near for course offering. eduCourse (currently in last call). 31

32. Service Provider / (Target) Service Provider (gari) Identity Provider (wasabi) Browser User Apache (1.3 or 2.0) / Tomcat Web server / Servlet container or IIS 5.x or 6 32

33. Shib Features for Service Providers • WAYF for federations, other options configurable • Authentication method can be passed in attribute assertion for fine tuning risk management • A site may have a public face with specific links that invoke Shib 33

34. Services you might not have thought of Shibbing • Roaming Access to WLAN • http://www.terena.nl/conferences/tnc2004/ programme/presentations/show.php?pres_id=165 • Mikael Linden, CSC, the Finnish IT center for Science • RADIUS-based access controller is a Shibboleth service provider • Network access control decision based on user’s “home” attributes 34

35. Services you might not have thought of Shibbing • Portal as Shib Service • Apache in front of Portal on Tomcat • Other approaches under consideration 35

36. Coming Shib Features for Service Providers • PKI-based direct-to-target scenario • Cert would contains • (possibly opaque) subject id • Identifier for associated Identity Provider • Would eliminate the first several steps in the classic Shib flow diagram • First Service Provider contact to Identity Provider would be the request for attributes • Lots of points of agreement to be worked out 36

37. Multi-campus system deployment model 1 CampusA IdProv CampusB Service Provider CampusB IdProv Browser User Apache (1.3 or 2.0) / Tomcat Web server / Servlet container or IIS 5.x or 6 CampusC IdProv CampusD IdProv CampusE IdProv 37

38. Multi-campus system deployment model 1 • Identity Provider per campus (vs. System IdP model) • Create a system federation (some policy & configuration work here) • Any campus can put up Shibbed service • Or a system library can offer system-licensed resources • Each campus retains control of Identity Management--high autonomy model 38

39. Multi-campus system deployment model 2 CampusA Dir Browser User System-level Identity Provider Service Provider Service Provider Service Provider CampusB Dir Service Provider CampusC Dir 39

40. Multi-campus system deployment model 2 • System-level Identity Provider model • Significant campus-to-system metadirectory infrastructure • Create a system federation (some policy & configuration work here) • Any campus can put up Shibbed service • Or a system library can offer system-licensed resources • More seamless “system citizen” experience 40

41. Coming: Shib breaks free of the browser • Number of open source projects are exploring this space • A pure Java implementation of Service Provider components of Shibboleth (now in beta) will really open the door 41

42. Joining and leveraging federations • InCommon: See participant agreements on the web site • http://www.incommonfederation.org • Talks much more about IAM infrastructure than Shibboleth per se • Other documents 42

43. Federation givens • Key attributes, their syntax and semantics • eduPersonAffiliation • faculty, student, staff, employee, member, alum, affiliate • eduPersonScopedAffiliation • member@ohio.edu • eduPersonEntitlement 43

44. eduPersonEntitlement in InQueue “If a Federation member sends or receives an eduPersonEntitlement Attribute Assertion containing the InQueue policy uri and containing the value urn:mace:incommon:entitlement:common:1 The semantics should conform to this definition: The person possesses an eduPersonAffiliation value of faculty, staff, or student, or qualifies as a "library walk-in". 44

45. eduPersonTargetedID Service providers or directory-enabled applications with the need to maintain a persistent but opaque identifier for a given user for purposes of personalization or record-keeping. Identity or service providers or directory-enabled applications with the need to link an external account to an internal account maintained within their own system. This attribute is often used to represent a long-term account linking relationship between an identity provider and service provider(s). Note that such a service provider might itself also be an identity provider. 45

46. eduPersonTargetedID It MAY be a pseudorandom value generated and stored by the identity provider, or MAY be derived from some function over the service provider's identity and other principal-specific input(s), such as a serial number or UUID assigned by the identity provider. It MUST NOT exceed 256 characters in length. 46

47. Multiple Federation scenarios • Simplest example: US IdP and UK IdP accessing an Open University course hosted in UK • US Institution is an InCommon member • UK institution belongs to a UK federation • Open U. Service Provider has to belong to both to serve members of both federations 47

48. Multiple Federation scenarios • Likely scenario: US Universities with Medical Schools will have to support both • InCommon & • Some Health Science federation(s) 48

49. How many federations? How many levels of federations? • An umbrella level: e.g., InCommon • Hard, foundational topics handled here: • Trust/risk framework • Attributes, syntax, semantics • Under that umbrella, any number of Communities of Interest (or Virtual Organizations) who build on the foundation • Profiles, refinements, extensions 49

50. Q & A • http://shibboleth.internet2.edu • Which of these issues seem tough, confusing to you? 50