# Presentation: 148689

## Shibbolethand SRU

- John PaschoudPERSEUS Project, LSE Library

- or, You can’t have everything you _**want**_, but the Web should know what you _**can**_ have

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## “I want my browser to recognize the information in web pages...”
I want my browser to recognise ME
“I want to keep control over which services are offered...”
But, sadly, I don’t have the power/money to control as much as Rupert Murdoch / Bill Gates / {insert your least-favourite capitalist media baron here}
...so I want my browser (and the services) to know that I have some powerful friends, too

- I want my browser to recognise _**ME**_
*“**I want to keep control over which services are offered...”*
- But, sadly, I don’t have the power/money to control as much as Rupert Murdoch / Bill Gates / {insert your least-favourite capitalist media baron here}
- ...so I want my browser (and the services) to know that _**I**_ have some powerful friends, too

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## [Outline]

- 	(More questions than answers)
- How Shib works over HTTP
- Does SRU _need_ Access Management?
- What sorts of ‘license terms’ (AAPs) might a SRU service impose?
- Can a SRU service explain its’ AM terms?
- How would a SRU client authenticate as a user?

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## [Acknowledgements]

- Simon McLeish, PERSEUS Project
- John Gilby, InforM25
- Wilbert Kraan, CETIS
- Markus Buckhorn, ANU
- Francisco Pinto, OUCS
- Spencer Thomas, JSTOR
- Pete Johnston, UKOLN
- Scott Cantor, Internet2 *(the Real Mr Shibboleth!)*
*Many others were referred-to*
*...**but you’re probably here!*

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## How Shibboleth works

- What the end-user sees
- (but only if he looks *closely!*)
- The global architecture

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## [demo1]

- user at LSE chooses a shibboleth-enabled  service, at Columbia

*Note that this illustrates the ‘worst case’ – in which the user has started a virgin browser session on a shared workstation, and no mechanism is being used to automatically indicate which institution the user is from (such as links provided by a library portal)*

- SRU Implementors Workshop, The Hague

- 03-Mar-06

**Notes:**
LSE and Columbia Universit (New York) are sharing an anthropology resource developed by Columbia. 

NB this demo illustrates a new browser session.

An LSE user wants to access a Shib-enabled resource hosted by Columbia. The user navigates to the resource hosted by Columbia. The resource is protected. 

## [demo2]

**WAYF**  - *in this case of a very simple federation, with just two member organisations. **This WAYF is hosted at Columbia.edu*

- SRU Implementors Workshop, The Hague

- 03-Mar-06

**Notes:**
The user is redirected to the ‘Where are you from’ (WAYF) server (hosted at Columbia.edu) which basically displays a list of all organisations that signed up to the federation. 
NB There are a number of ways in which this list can be reconfigured if the list of members is very long.

## [demo3]

-  authentication*(note server is at LSE.ac.uk, not Columbia.edu)*

- SRU Implementors Workshop, The Hague

- 03-Mar-06

**Notes:**
The user selects his home institution (LSE) from the list and a standard LSE login box (which is already very familiar to the user) pops up.  
The user types in his u/p. 

## [demo4]

- handle request

- SRU Implementors Workshop, The Hague

- 03-Mar-06

**Notes:**
The user is redirected to the requested site... 

## [demo5]

- user reaches secure resource

- SRU Implementors Workshop, The Hague

- 03-Mar-06

**Notes:**
The user reaches the protected resource.

## How Shibboleth works

- The resource host is a **Service Provider** (SP)
- The organisation to which the end-user belongs is an **Identity Provider** (IdP)
- The SP(s) and the IdP(s) *may* belong to a Federation, which could:
- Set standards for trust between parties
- Operate a common ‘Where Are You From’ (**WAYF**) service, listing IdPs
- I don’t have any salt-cellars, pepper-pots or other table-ware, so I’ll just have to make do with this old diagram from SWITCH

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## Shibboleth Architecture

**Resource**

**WAYF**

**Users Home Org**

**Resource Owner**

- SRU Implementors Workshop, The Hague

- 03-Mar-06

**Notes:**
The Shibboleth System requires four major components: 
The user that wants to access a protected web resource 
The Identity Provider (IdP), which installed Shibboleth software - the institution with which the user is registered (e.g. a library, university, ‘virtual’ organisation) 
The Resource Provider (ReP), which installed Shibboleth software – the website that hosts the resource that the user wants to access (e.g. JSTOR). As access to the the required resource is restricted, the Resource Provider has an access control system to decide whether the user should be allowed to access the resource, and if, yes, at what level.
The ‘Where Are You From’ (WAYF) service. This is a ‘central’ service, operated on behalf of a Shibboleth Federation, which provides a list of organisations whose users may access the resource.

The user (Alice) is a student who wants to access a protected resource to which her institution subscribes. Her student registration information is stored in the institutional user database. 

Alice navigates to the resource using her web browser. Access to the resource is protected and so requires proof that Alice is eligible to access the resource.
The Shibboleth software redirects the browser to WAYF. 
The WAYF server displays a web page with a drop-down menu from which Alice selects her ‘home organisation’ (LSE).
(4)When Alice selects her home organisation (LSE), her browser returns her selection to the WAYF.
(5)The WAYF then redirects her browser to the LSE Handle Server. The Handle Server has access to the user database and 'knows' how to authenticate a user based on his/her credentials (e.g. username and password). 
(6)The Handle Server produces a standard LSE web login screen. 
(7) Alice enters her LSE username and password.
(8) Provided the credentials are correct, the Handle Server generates a digitally signed Handle on behalf of Alice. A handle is basically a session identifier. The Handle is sent to the SHIRE (Shibboleth Indexical Reference Establisher) of the resource Alice wants to access. SHIRE passes the received Handle onto the SHAR (Shibboleth Attribute Requestor).
(9) The SHAR then sends the Handle back to the Attribute Authority (AA) of the home organization via a secure HTTP connection. 
(10) The Attribute Authority verifies the Handle with the Handle Server. If it is valid, the AA checks which attributes (information about the user, e.g. course details) it may release to the resource based on the LSE Attribute Release Policy (ARP). The AA then sends the relevant attributes to the SHAR. 

NB Steps 7-10 are completely invisible to Alice, as it is server-to-server communication. 

(11) Finally, the SHAR passes the received attributes to the Access Control Manager. The Access Control Manager checks the received information and decides whether the user should be granted access. If access is granted, the user gets access to the resource.

## Role-based vs Identity-basedAccess Management

- The license between LSE and Elsevier, that enables _me_ to use ScienceDirect, is based on my _*role*_
- (Staff@LSE.ac.uk, or Member@LSE.ac.uk)
- ...scoped by my _*affiliation*_ with the LSE: eduPersonScopedAffiliation
- ..._not_ on my _*identity*_
- (J.Paschoud@LSE.ac.uk)
- Sometimes my location (158.143.162.28) is useful
- but this is largely a legacy of the library-as-building-with-books era
- Even if I want to use personalisation features of a service, I _could_ do so pseudonymously
- (_[User124451@LSE.ac.uk](mailto:User124451@LSE.ac.uk)_)
- Or even with an anonymous identifier that’s repeatable, but unique to _my_ use of _just one_ service: eduPersonTargettedID
- (so different services can’t compare notes with each other)

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## Does SRU need AM (at all)?

- Some commercial search targets are licence-restricted (IBSS, MIMAS, INSPEC, Compendex, CAB)
- but most just _intend_ to protect _content_, not metadata
- Some ‘public’ search targets may be privacy-restricted   ...or otherwise secret
- weaponsofmassdestruction.gov.iq ??? *(subject to redelegation)*
- Policy issue: Do you list for a user resources to which he has no (current) access?    (...& how do you know?)
*(a long-standing religious division between two fundamentalist librarian sects)*
- More likely, as semantic Web/Grid offers richer content _as_ (meta)data

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## Are the costs (of effective AM) worth the benefits?

- A user, and his IdP may be more remote from a specific x-search target (than from a simple file of downloadable content)
- AM of _user_, where x-search client is a portal (etc)
- Maintaining access policy metadata and recognised IdPs/roles isn’t trivial on a large scale
- Access agreements/licenses are usually 1:1 between SP and IdP (as with e-journals); AM federations could help to scale this, but wouldn’t address most use-cases for AM in SRU

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## Advantages of Shib over alternative AMs, for SRU services

- AM by scoped affiliations (ePSA, e.g. ‘staff@*.ac.uk’) may fit well with intended scope of SRU services that need to restrict access
- Relatively low-maintenance for service provider
- no name/password or IP-range lists
- Shib is good for services over HTTP, not currently adapted to other protocols
- WebServices are for interop _between enterprises_; Shib is for AM _across domains_
- Shib is likely to be widely and globally adopted by academic communities

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## How do SRU and Shib relate in Service Oriented Architecture models?

- (along with other services relating to access)
- JISC / ‘Common’ Information Environment
- JISC / DEST e-Framework
- (these are not very helpful, yet, in explaining _how_ services interoperate)

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## JISC Information Environment

**Andy Powell, July 2003+ ****(http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch/)**

- JISC Information Environment

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## JISC / DEST e-(learning)Framework

- JISC / DEST e-(learning)Framework

**(http://www.elframework.org/framework//)**

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## Can a SRU service explain its’ AM terms?

- By embedding in explain profile?
- or should this be restricted to protocol consumption purposes?
- By reference to an ‘explain’-type response from an associated Shib SP?
- Has been mooted, but not yet developed
- Could be more widely useful
- By inclusion in Service Registries and Service Description Schemas?
- Would this help m2m access between SRU clients and services?
- Should SRU (and similar services) be specifically accommodated in the eduPermission OC? (see: signet.internet2.edu; RFC by 29-Aug-06)
- AM ‘terms’ are contained in the Attribute Acceptance Policy (AAP) of a Shib SP 

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## SP config (aap.xml)

- <AttributeAcceptancePolicy xmlns="urn:mace:shibboleth:1.0"xmlns:xsi=http://www.w3.org/2001/XMLSchema-instancexsi:schemaLocation="urn:mace:shibboleth:1.0/usr/share/xml/shibboleth/shibboleth.xsd"><!-- Filtering rule to limit values to eduPerson-defined enumeration. -->            <AttributeRule Name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation“Scoped="true" CaseSensitive="false" Header="Shib-EP-Affiliation" Alias="affiliation">        <AnySite>            <Value>MEMBER</Value>  <Value>FACULTY</Value>            <Value>STUDENT</Value>  <Value>STAFF</Value>        </AnySite>       <!-- Reject values from particular IDP -->        <SiteRule Name="urn:mace:inqueue:shibdev.edu">                <Scope Accept="false">shibdev.edu</Scope>                <Scope Type="regexp">^.+\.shibdev\.edu$</Scope>        </SiteRule>    </AttributeRule><!-- Pass through any scoped value (by matching regexp) and change name of attribute -->    <AttributeRule Name="urn:mace:dir:attribute-def:eduPersonPrincipalName" Scoped="true" Header="REMOTE_USER" Alias="user">        <AnySite>    <Value Type="regexp">^[^@]+$</Value>    </AnySite>    </AttributeRule>
- <!-- Pass through any value-->    <AttributeRule Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10“        Header="Shib-TargetedID" Alias="targeted_id">        <AnySite>    <AnyValue/>    </AnySite>    </AttributeRule></AttributeAcceptancePolicy>

- SRU Implementors Workshop, The Hague

- 03-Mar-06

**Notes:**
ARP: largely self-explanatory, as long as it is realisedthat all the ARP files in the configured directory will be applied. 

Each rule has a single target element, but may contain multiple attributeelements. The release tag can be set to "permit" or "withhold" to modifyearlier rules in the file or rules in other files; the default behaviouris to withhold any attributes not explicitly released by a rule. (TheIdP also only passes attributes that are asked for by the SP, whateverthe ARPs say.)N.B. Attributes to be released need to be listed in ARP and resolver files!

## How would a SRU client authenticate as (for) a user?

- Shib (currently) assumes a browser as client, and a human user to interact with
- ...there are solutions for portals, interacting with local authentication services
- ...which in turn can provide the auth’n front-end to a Shib IdP
- such as cacheing browser login to portal
- (Bad news) There’s a wide diversity of local WebAuth’n mechanisms
- (Good news) This requirement is common to other proxied services too
- ...Assuming a simple permit/deny (no interaction expected), based on the default Attribute Release Policy (ARP) of the users’ IdP  

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## IdP config (arp.xml)

- <?xml version="1.0" encoding="UTF-8"?><AttributeReleasePolicyxmlns:xsi="_[http://www.w3.org/2001/XMLSchema-instance](http://www.w3.org/2001/XMLSchema-instance)_"xmlns="urn:mace:shibboleth:arp:1.0"xsi:schemaLocation="urn:mace:shibboleth:arp:1.0 shibboleth-arp-1.0.xsd" >  <Description>LSE Site ARP.</Description>    <Rule>      <Target>        <AnyTarget/>      </Target>      <Attribute name="urn:mace:dir:attribute-def:eduPersonAffiliation">        <AnyValue release="permit"/>      </Attribute>      ... more attribute tags ...    </Rule>  <!-- Attributes required in specific situations by individual SPs -->    <Rule>      <Target>        <Requester>_[https://wiki.it.ohio-state.edu/shibboleth](https://wiki.it.ohio-state.edu/shibboleth)_</Requester>      </Target>      <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName">        <AnyValue release="permit"/>      </Attribute>    </Rule>    ... more rules ...</AttributeReleasePolicy>

- SRU Implementors Workshop, The Hague

- 03-Mar-06

**Notes:**
ARP: largely self-explanatory, as long as it is realisedthat all the ARP files in the configured directory will be applied. 

Each rule has a single target element, but may contain multiple attributeelements. The release tag can be set to "permit" or "withhold" to modifyearlier rules in the file or rules in other files; the default behaviouris to withhold any attributes not explicitly released by a rule. (TheIdP also only passes attributes that are asked for by the SP, whateverthe ARPs say.)N.B. Attributes to be released need to be listed in ARP and resolver files!

## Further Information

- JISC Core Middleware activities: www.jisc.ac.uk/programme_middleware.html
- Shibboleth: _[shibboleth.internet2.edu](http://shibboleth.internet2.edu/)_
- Signet / eduPermission: signet.internet2.edu
- Internet2 mailing lists:
- shibboleth-announce
- shibboleth-users
**Shibboleth at LSE: **www.angel.ac.uk/ShibbolethAtLSE/
**Ideas that you want to share after the Workshop:**
- J.Paschoud@LSE.ac.uk
- (because my train is at 17:36 from Den Haag HS)

- SRU Implementors Workshop, The Hague

- 03-Mar-06

## So... show me Shibboleth, actually working

- Some Shibboleth-enabled resources:
- http://auth.athensams.net/setsite.php?id=urn:mace:eduserv.org.uk:athens:provider:lse.ac.uk[Athens-Gateway resources available to LSE users]
- https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/ShibOnedotThree[Shibboleth Wiki at Ohio State]
- https://dart.columbia.edu/secure/gandhi-timeline/sect_5[LSE access to DART anthropology resources at Columbia, NY]

- SRU Implementors Workshop, The Hague

- 03-Mar-06