CAMP Shibboleth: Enabling Campus and Federated Single Sign-On, Day 1

CAMP Shibboleth: Enabling Campus and Federated Single Sign-On

Also see

• CAMP Shibboleth: Enabling Campus and Federated Single Sign-On, Day 2
• CAMP Shibboleth: Enabling Campus and Federated Single Sign-On, Day 3

To post comments on the camp,

Slides at (or coming to)

Presentation 1:

Introduction to Shibboleth and Phases for Deployment

Steven T. Carmody, IT Architect, Brown University

What is Shibboleth

• MACE model (look up MACE)
• Shib Project: umbrella of activities aroudf federated auth and access
• Shib Specifications 1.1, protocols and conformance
• SHib System: implementation by internet2 of the specification, with some value added features
• open source apache lciense
• inter and intra web sso. the INTRA is something new in last 18 months
• implements SAML Browser/POST and Browser/Artifact, designed tSAML-enable applications
• portable, minimal, using pre-existing authentication and attribute sources
• base don oAISIS SAML specification
• interoperates with many vendor products (like what)
• attribute-based single sign-on, Attribute may include identity but is optional, location independent – not ip based
• can manage privacy via Attribute release policies (ARPs), Site, groups, and institution can limit what attributes available
• extensible authentication and attribute sharing: federation defines syntax and semantics of common attribute/values pairs
• Shib v1.0 a profile of SAML v1.1, archetocture describes how shib uses SAML, extends SAML defining a new NameIdentifier
• trust fabric baed on PKI
• Success in Europe is twisting arm of vendors tsupport

is NOT

• useable sans browser
• identity management
• directory or database
• complete solution teverything
• world class SSO (baed on SAML 1.0)

Status

 Roadmap

Vendors & federations

Deploying

• o intra-campus Web SSO
• o intra campus delivery of attributes
• o federated authentication
• o inter-federation operation
• o supporting local sites: custom install instructions, custom shib config files, custom error files, metadata distribution, new business process, how to register, help desk support
• o about those new business processes: are campus website required to use the campus SSO? How does a site apply to be a recognized SP? Support and problem resolution

Why chose shib

• o use same so for intra and inter
• o easy evolution from intra the inter to large federations
• o Service Provider support for several different web servers
• o increasingly, campus applications need attributes
• o formal policy frameworks http://www.ucop.edu/irc/itlc/uctrust/welcome.html
• o federations: scholarship now done via net, access to partners is ismplified

Managing the local federation

• o trust: CA, self signed certs, revocation
• o managing metadata of service providers
• o managing attribute release
• o browser user navigation (local WAYF, IdP)
• o define standard attributes

Managing Intra-campus delivery of attributes:

• o growing number of apps need attributes. SHibboleth can do that without direct access to LDAP or other messy systems. Why are they using them? Access control and user profiles. Federated attributes are better for security — service provider applications don’t need to store the data.
• o identify sources (ldap? peoplesoft?)
• o identify attributes, process to update list, who decides to release X attribute x to service y
• o define policies for handling attributes
• o help desk: problem resolution flow when user denied access: who can see whether user has proper attribute, process to get correct attributes, contact pints in department

Session 2: Case Studies of Campus and Federated WebSSO

Paul Caskey —

• o reduce sign-ons, improve security, establish plug n play infrastructure for collaberation
• o guest wireless system: biggest Shibboleth leverage device as visiting administrators from federated IT schools could read email why other could not
• o financial reporting: don’t care about how the car works, just want to drive. really served as learnoing experience for customer support
• o shibbed blackboard at health science center, houston
• o employee training and research tracking. lots of identifier issues
• o Lessons learned: educate developers on technology, trust, authorization; pursue low hanging fruit early; communicate, promote consistent, understanding of technology, set expectations; identifiers namespace and lifetime; support models who-where-skills-tools (especially when client from federated rather than local institution)

Scotty Logan

• o they use their own WebAuth + WebAuthLDAP
• o serves unix, linux, osx only
•  uses SUNEt ID;s, which have issues (retired, never reused, no distintction between faculty, stafff or simply sponsored)
• o shib in phase 1 status, co-existing with WebAuth
• o current driver is actually guest access, in particular libraries

R.L. "Bob" Morgan

• o wrote Pubcookie & WebLogin (extension to kerberos) in 1998, used by 700+ campus sites, some 3rd party products
• o pros and cons for switching to shib: shib missing some features they need vs pubcokie not extensible in some ways. hoping to promote shib to 3rd parties, new applications; meanwhile run things concurrently
• o dealing with commercial services: commerical service wanted email, registrar said no, so used eduPersonTargetedId ( a inique pseudo ID)/ vendor used this as a "value added" security feature they could gloat over
• o application: outsourcing charitable giving. were able to push state to push vendor. Odd bit: vendor wanted guy with tie to provide 24/7 support.
• o integrated local community colleges