Web based single sign on Caleb Racey, Web development officer, Webteam, customer services, ISS IAMSECT project officer, Systems admin (focusing on SSO)

Agenda The need for SSO Shibboleth Theory –Technology overview –How it works Practicalities –How to install it –What to do afterwards

Shibboleth Theory The need for single sign on (SSO) –User perspectives – Admin perspectives The future of SSO –Shibboleth –What it is –How it works

The need for web SSO Proliferation of web based systems VLEs (Blackboard, Zope, webCt, Moodle) Library catalogues Webmail ePortfolios eJournals and eResources Grid etc

The need for web SSO Proliferation of password stores in an institute: Campus login Library login Medical school login Comp Sci Login Athens Lack of integration even when one username and password still many logins Users and administrators overburdened

User Survey Quantify burden on Users 200+ participants iPod shuffle prize 1 winner =

Users overload, Survey says:

Summary of survey Users overloaded with different passwords and overloaded with login prompts Half are using best practise with passwords Half are not! Current web username and password provision needs improvement.

Administering a password system Easy to setup, the pain comes later once people use it: Technical pain Securing the system Backing up the system Clustering the system Administering the system

Management pain Adding new users Expiring old users Changing passwords Distributing passwords Ensuring “proper” passwords used Administering a password system

Real world example

Real World example

Summary User are overloaded with authentication tokens already There is explosive growth in the use of username and passwords Administering usernames and passwords is painful and expensive.

The Solution One university password store: –One password to remember –One set of admins –One set of infrastructure –One education effort In Ncl: pre-existing Campus username and password - stable, robust well resourced For the Web Web Sign On and Shibboleth

Shibboleth Why the daft name? Shibboleth: And the Gileadites seized the passages of the Jordan before the Ephraimites; and it was so, that when those Ephraimites who had escaped said, "Let me go over," that the men of Gilead said unto him, "Art thou an Ephraimite?" If he said, "Nay," then said they unto him, "Say now 'Shibboleth.'" And he said "Sibboleth," for he could not frame to pronounce it right. Then they took him and slew him at the passages of the Jordan; and there fell at that time of the Ephraimites forty and two thousand. (Judges 12:5-6, King James Version of the Bible)Gileadites JordanEphraimitesJudgesKing James Version of the Bible i.e. The first recorded use of a password

Shibboleth Federated Single Sign on standard from American Unis via Internet2 Based on SAML (Security Assertion Markup Language) Summary: Athens and Microsoft passport functionality combined with added privacy

What you need to know about shibboleth How it works What attributes are What federations are Your Identity stays at home Privacy sensitive by default Terminology Identity provider (IdP): The password store e.g. ncl Service provider (SP): The application owner e.g. ejournal

The core concepts of shib Usable for on and off campus resources A user is authenticated at “home” Home knows who and what a user is Service providers make access decision based on what a user is Service providers should only know the minimum about a user Builds on top of pre-existing sign on (pubcookie)

Core concepts of shib (technical) User redirected to home to authenticate and redirected back once authenticated. Authorisation is based on attribute description of a user sent between the two servers in the background Federations are used to group together service providers and institutes who can agree to the same rules

What the user sees

User attempts to access Service

User redirected to ‘WAYF’

User selects their Identity Provider

IdP authenticates User Active Directory

User redirected back to Service Active Directory

HS?...

User accesses Service Active Directory

Shib for unfederated apps Active Directory WAYF is transparent and optional

Shibboleth “Shibboleth, is a bit like the duck which moves serenely through the water, but is paddling furiously beneath the surface.” - Derek Morrison, the Auricle

Shibboleth Process Simplified User accesses protected resource......credentials and agreed information passed back to service provider user is redirected to their home institution for authentication... 2

Benefits of shib Federated access control ! Allows access control based on attributes i.e. enhanced authorisation Allows “secure” access control over http and https Prevents application developer from having to worry about login process

Demonstration (live) EDINA EMOL SDSS federation WAYF

Attributes Attributes are what shib uses to authorise. Descriptive information about a user Can technically be any descriptive text e.g. has green eyes Privacy sensitivities mean external attributes limited Internal attributes not so limited

How to identify useful attributes (theory) the attributes that are required by the web application; your institutes privacy policy; which attributes you can collect in a timely and scalable manner;

Identifying attribute (reality) Type and format will be decided by the federation you join Different Federations still likely to use the same standards You are not limited by federation, it is just there for convenience

Attribute identification (detail) For external consumption current attribute use is limited to a dull but useful core One major attribute standard in real use at present: EduPerson One current seriously used attribute: edupersonScopedAffiliation

eduPersonScopedAffiliation MACE-Dir eduPerson attribute Example: Gives subject’s relationship to an institute At present can be one of: member, student, employee, faculty, staff, alum, affiliate. Many resources licensed on these terms “member” is all providers want to know for now

Attribute identification (detail) Several more contemplated: eduPersonPrincipalName eduPersonTargetedID Given name Surname Common name eduPersonEntitlement

eduPersonPrincipalName MACE-Dir eduPerson attribute Examples: Equivalent to username Must be long lived and non recycled Must be unique

eduPersonEntitlement MACE-Dir eduPerson attribute Examples: – –urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted states user’s entitlement to a particular resource Service provider must trust identity provider to issue entitlement Good fine grained fall-back approach.

eduPersonTargetedID MACE-Dir eduPerson attribute Example: A persistent user pseudonym, specific to a given service, intended to enable personal customisation Value is an uninformative but constant Allows personalisation and saved state without compromising privacy…much Issues about stored vs. generated forms In flux at the moment

Attribute use in the Real world SDSS usage for Edina resources: eduPersonScopedAffiliation: Biosis, EMOL, Times archive, EIG, Zetoc Alert, Zetoc Search, Hairdressing eduPersonTargetId Zetoc search eduPersonPrincipalName: LandMap

Attributes for internal use To be determined by the needs of application developers e.g. users department, course, year of study, undergraduate or postgraduate, outstanding fines etc. To be decided in consultation with application developers

Internal attributes (technical) Need to be accessible in 3 seconds LDAP or SQL querying ideally consistent for different user groups, i.e. staff and student attributes are in the same place.

Advanced attributes N-tier authentication Potential to distribute “tokens” as attributes e.g. NTLM or Kerberos tickets Might be a solution to the n-tier problem i.e. allow a portal to tell a user if they have new without the portal having “read everything” permissions on mail store

Privacy sensitive Attributes once aggregated are filtered twice: Site wide policy as to what to release to that service Overridden by User defined policy as to what can be released

Attribute release policies Attributes filtered through 2 release policies: Site policy for all users arp.site.xml User policy for that user arp.$Username.xml User policy overrides site policy (for paranoid users)

Attribute exchange format Attribute passed as SAML assertions SAML supports exchange of most meaningful information Text –Kerberos tickets –Images?

What is SAML Security Assertion Markup Language Xml for saying what someone is. SAML = accepted and used standard (MS/IBM/Sun/SAP/Oracle etc)

What SAML looks like urn:mace:ac.uk:sdss.ac.uk:provider:service:emol.sdss.ac.uk urn:mace:ac.uk:sdss.ac.uk:federation:sdss _1b4b75b3d32cd5as1237s qensad8h member ncr18

Federations Club of institutes agreeing to attribute formats and code of conduct Organisational convenience, not technically necessary, easy enough to bypass and setup agreement between two parties independently Designed to cut down managerial overhead of having a relationship with many service providers Can be in multiple Federations and have Bilateral Agreements.

UK Federations Development SDSS federation Production - UK Access Management Federation Launches in September - for HE and FE SDSS membership will roll into production federation Athens: Test federation for shib/athens Gateway

Bilateral Deployment Shib has no need for a federation. Federation handy place to stick the rules, procedures, advertise services Deployment possible with no federation

Why we are backing shibboleth Many competeing standards: MS passport, liberty alliance, Ping identity Shib has the momentum and drive in our sector Standards based so interoperable. “Identity + Access management is a process not a technology” -Gartner i.e. The approach is more important than the technology.

Shibboleth momentum worldwide Actively Used in America, Switzerland, Finland Australia, Hungary, Croatia actively deploying Rest of Europe contemplating American government looking at for governmental apps Microsoft and Sun both interested in SAML/shibboleth, SAP SAML based, IBM interested. SAML technical editor = Shib lead developer

Momentum UK JISC funded core middle ware program £7 million over next 3 years BECTA has settled on shibboleth NHS in early stages but interested Athens will be fully Shib compatible by 2007 Regionally: £200k has come to Newcastle/Durham £40k regionally via EPICS

Shibboleth in Newcastle IAMSECT project JISC funded, collaboration with Durham and Northumbria SAPIR project Newcastle Library based EPICS ePortfolios tag on Life long learning portfolios transferable between NORMAN institutes

IAMSECT Pilot study: federated access to resources between Durham and Newcastle Medical students already shared Shib enable Durham blackboard Newcastle Zope VLE Newcastle Blackboard Learn lessons with medics then role out for entire student population.

SAPIR Replace Athens with Shib Metalib portal Shib access Access to the Reading list management system. Aleph Library Management system access

The future of SSO technology SAML standard about to hit 2.0 Support for multifactor auth Single sign out Support for browserless apps e.g. Lionshare Liberty alliance (Sun&co) Microsoft, SAP converging on SAML

Theory of shib, summary Single sign on badly needed What shib is How it works The core concepts The technology Federated single sign on a reality Momentum is behind shib

Shib, How to do it

Installation Guides Overview –Password stores –Certificates –Federations –Attributes –Release policies Special cases (windows, no federation)

Installation Guides Guides at: Guides are Mature, shib no longer bleeding edge

Overview Setup the software: Use Shib 1.3 much easier and better Guided install via ant Draft docs at Tricky bits Authenticate against password store. Get https Certificates. Join federation's Setup Attributes

Authn against Password Store Choose: 1) password store -.htpasswd, Active Directory, NIS, kerb, Radius 2) login technology; - sets $REMOTE_USER on apache Pubcookie CAS mod_auth_kerb mod_auth_*

Pubcookie In use for 2+ years Stable resilient infrastructure Apache and Microsoft IIS Can use LDAP or Kerberos to authenticate Can used unix NIS (potential for migration) Supports multiple Auth e.g. password and secure-Id number Possibly to heavy weight, Do something lightweight with mod_auth_*

Certificates Magic incantations: openssl req -new -key idp.key > idp.csr.2006 Ugly + opaque + fiddly, but easy to do with a recipe Signing: Signing by CA required for Trust chain. Thawte, Globalsign, SDSS, Athens For 2 federation deployment (e.f. SDSS + athens) then they need to share a CA and you have to use that.

Multiple CAs on one site AA needs to be on separate virtual server from the login page. Most shift the port login, cert = shib.ncl.ac.uk.crt (thawte signed ) AA, cert = shib.ncl.ac.uk.crt (thawte signed ) Can use a separate virtual server login, cert = shib.ncl.ac.uk.crt (thawte signed ) AA, cert = aa.ncl.ac.uk.crt (SDSS signed )

Joining Federations Admin: SDSS: Letter on headed paper from high up saying you will behave Athens: Password policy audit Fill in large form, talk to your Athens admin compatible CA signed cert. Athens and SDSS both support Thawte: can use same one

Certificates Required to communicate securely. Signing by CA required for Trust chain. Which CA ? Prototyping, SDSS Athens - free, easy. Globalsign, Thawte, verisign - £100 per year, easy once setup, setup is nasty.

Attributes administration The process of setting up an attribute: Aggregation Release Acceptance

Aggregating Easy Attributes <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:eduPersonAffiliation">

Heavy weight Attributes <JDBCDataConnector id="db6" dbURL="jdbc:mysql://thing.ncl.ac.uk/database?user=thing&password=thing" dbDriver="com.mysql.jdbc.Driver" maxActive="10" maxIdle="5"> SELECT course_code, CASE course_code WHEN 'A101' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted' WHEN 'A106' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted' WHEN 'O106' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted' WHEN '3019P' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted' WHEN '3384P' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted' WHEN '5826P' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted' ELSE 'none' END as sdssentitlement FROM CMstudentdata WHERE loginid = ?

Release policies ARP.xml EMOL service at EDINA urn:mace:ac.uk:sdss.ac.uk:provider:service:emol.sdss.ac.uk urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted

Release policies AAP.xml <AttributeRule Name="urn:mace:dir:attribute- def:eduPersonAffiliation“ Header="Shib-EP-UnscopedAffiliation" Alias="unscoped-affiliation"> ^[M|m][E|e][M|m][B|b][E|e][R|r]$

Complex attributes Use case Generation Problems Lessons learned

Complex attributes: Example “Medic restrict” Accessing medical content at EMOL Subset of resources e.g. Autopsy content Requires entitlement attribute: edupersonEntitlement urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted

Complex attributes: students “Relatively” easy for students- SimpleAttributeDefinition id="urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk“ sourceName="sdssentitlement“ SELECT course_code, CASE course_code WHEN 'A101' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted' WHEN 'A106' THEN 'urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted' ELSE 'none' END as sdssentitlement FROM CMstudentdata WHERE loginid = ? Find out if student is on one of three medical courses

Complex attributes: Staff Staff, registered manually over years Pick their own usernames, own address – most didn’t address No connection between Athens id and Newcastle id NHS staff have ncl usernames Solution?

Admin Problems No tools to help the admin (yet) Editing verbose opaque xml files by hand Looking in verbose opaque log files Asking others to look in verbose opaque log files at their end Security gets in the way Magic is cool flexible but hard to grasp.

Reality check Shibboleth setup is relatively easy! Recipes will get you a working usable install: - you don’t have to understand it all to use it Most of the complexity comes with advanced use cases. Techies like me talk about problems not successes

Technical help Us – MATU Internet2 – – – state.edu/twiki/bin/view/Shibboleth/WebHomehttps://authdev.it.ohio- state.edu/twiki/bin/view/Shibboleth/WebHome SDSS federation – –

Windows Installation Recent, Java only install on tomcat Needs ssl certs and keys in pks12 format c:\pki>openssl pkcs12 -export -in idp.crt -inkey idp.key -out idp.p12 - name "tomcat" -CAfile myRootCA.crt -caname myRootCA -CAfile myFirstIntermediateCA.crt -caname MyFirstInte[...] -chain May have Limited SAML profile support: - probably good enough.

SAML Profiles What are profiles? Different flows and use cases for exchanging SAML assertions. Profile defines constraints and/or extensions of the core protocols/assertions for a particular use case. Basically it a flavour of SAML to be used in a particular way

SAML Profiles The profiles: Post (default) IdP encodes the form data in an HTML form via the user's browser assertion to the SP. Javascript in th form allows auto-submit as a HTTP POST to the SP's assertion consumer service. The authentication assertion passes through the user's browser in the clear, in privacy sensitive environments it is not usual for attributes to be included (so-called AttributePush). Instead, the SP performs an attribute query to the IdP's attribute authority over an SSL-protected channel to acquire the subject's attributes. Artifact IdP returns an opaque reference (artifact) to attribute assertion to SP via an HTTP redirect. The SP dereferences it to acquire the original assertion by accessing the IdP's artifact resolution service Attribute Push (new) Delivery of attributes together with a SAML authentication assertion. Eliminates an extra SOAP callback/query for the attribute information. It is the default in 1.3 when the BrowserArtifact Profile is used, but can be enabled with BrowserPOST as well. In that case, attribute information will be pushed through the client and this may have privacy implications in some environments.

Post installation Creating a coherent user experience? Branding Error handling Hardening the install Monitorring Clustering

Branding user experience At present no Cohesive user experience: lack of clarity? user education problems?

Why Brand? Users know what the process is Can educate about security –Prevent spoofing, phishing They can complain about it properly : –i.e. not “the internet is broken again” Logos and branding

Support Issues Testing The need for testing How to test Access Problems: -why they will happen -what they look like -what should they look like

The need for testing The fantasy Shibboleth need accurate, easily locatable user information The reality Information stores are: dispersed, inaccessible, incomplete, out of sync, conflicting. Attributes accuracy is “a best effort” not a certainty Things will go wrong

Examples EdupersonScoped Affiliation Ability to login should = ncl affiliation - NHS staff -101 edge cases EdupersonEntitlement medic restrict urn:mace:ac.uk:sdss.ac.uk:entitlement:emol.sdss.ac.uk:restricted Identifying medics is hard, There will be plenty of problems

The problem of testing How do you test access control setup for all the different user types? Test users are difficult to setup, In multiple attribute store scenario they have to be in all stores. some stores don’t understand “fake users”

When things go wrong Middleware is invisible: - when it works - when it doesn’t - users unaware of what success looks like, therefore unaware of failure -federated content means federated errors Similar to networking problems

Access to EMOL Access without proper scopedAffiliation

Access without medical entitlement Tells you something is wrong However no obvious route to rectify it Access to EMOL

Local VLE Access by non med school user What improperly registered medics see

WAYFs The “Best Worst” solution - ugly but usable - itching for better solutions - not Technically necessary Need to get user from SP to IdP to login -Many approaches Standard WAYF Multi fed WAYF Direct linking Passing IdP as parameter Seamless WAYF

Auto WAYF redirection for users with a Kerberos login e.g. users on campus machines: Requires: Browser supports Negotiate authentication and permits use by WAYF. Kerberos cross-realm trust must exist between each IdP and the WAYF If Login server + browser support Negotiate then Auto login Degrades gracefully for home users.

Service Hardening Automated Monitoring Problematic: monitor across 3 sites: IdP, SP, WAYF. Monitor 4 stages Login Attribute aggregation Attribute release Attribute acceptance “Just because it is up doesn’t mean it is working”

Service Hardening Service starts hard: 2 years of operation, no daemon failures. Modular clusterable architecture, Login store (AD) clusterable weblogin cluserable Shib now clusterable (HAshib last piece in puzzle)

Questions?