Transcript Case Study: Attribute Delivery at Newcastle University

Tech Track: Attribute Delivery
Newcastle University
Caleb Racey
[email protected]
Overview
• Introduction
• Attribute Issues
–
–
–
–
External site access
Internal site access
Provisioning
Usability improvements
• Roundup
Technical Background
• Distributed ad hoc identity infrastructure
– No Authoritative directory of user info
– Identity information spread across diverse systems
• Mixed Infrastructure:
– Unix: Solaris + Redhat EL
– Windows
– SAP
• Mixed web application platforms:
– The 3 P’s: PHP, Perl, Python
– Java
– ASP + ASP.net
What attributes are used for
• Access control to external applications
– federated use
• Access control to internal applications
• Provisioning internal applications
• Usability internal enhancements
Prerequisites to attribute use
• Identify requirement for attributes
Do people actually know?
Chicken and egg,
won’t use Shib until attributes there, won’t know what they need until they try
• Identify Sources of Attributes
–
–
–
–
Data Integrity
Ownership issues
Cultural issues
Uses
• Data protection issues
– Can I release this?
• Service and support
– What to do on failure
– How to support devolved systems
Technical Stages, Attribute Delivery
• Aggregation
– Get Attributes from data stores
• Release
– Decide what information you will release to whom
• Acceptance
–
–
–
–
Decide what information you will accept
From whom
In what format
Mapped to what variables on the server
Attribute Release
• Determined by Site ARP and User ARP
e.g. Arp.xml + arp.ncr18.xml files
User Arp can be from LDAP
• Tools for user control
SHARPE- web based gui
Explanation + Email address on support site +manual intervention
• Problems: too complex for users?
Attribute release
ARP.xml
<Rule>
<Description>EMOL service at EDINA</Description>
<Target>
<Requester>
urn:mace:ac.uk:thing:provider:service:emol.sdss.ac.uk
</Requester>
</Target>
<Attribute name="urn:mace:dir:thing:eduPersonEntitlement">
<Value release="permit">
urn:mace:ac.uk:thing:entitlement:emol.sdss.ac.uk:restricted
</Value>
</Attribute>
</Rule>
Attribute Acceptance
• Map attribute to server variables (Header=)
Flexibility useful for supporting legacy e.g.
Map ncr18 to REMOTE_USER for legacy .htaccess
Map [email protected] to REMOTE_USER for federated apps
• Give Attribute alias for access config (Alias=)
Allow unscoped-affiliation member
• Determine what you will accept from whom
What <Value>
Whom
<AnySite>
<SiteRule>
<Scope accept=“true”>ncl.ac.uk</Scope>
Attribute acceptance
AAP.xml
<AttributeRule Name="urn:mace:dir:attributedef:eduPersonAffiliation" Header="Shib-EPUnscopedAffiliation" Alias="unscoped-affiliation">
<AnySite>
<Value Type="regexp">
^[M|m][E|e][M|m][B|b][E|e][R|r]$
</Value>
</AnySite>
</AttributeRule>
Fed use: What was required
• Identify Attribute requirements of providers
– Generally stated by the federation
– Can be bilateral agreements
– Generally not complicated
• Aggregate attributes
• Release
Simple Example
• Access to “Athens” journal resources
Via shib login gateway shib >> athen assertion conversion
Access to most journals
• Requires “Affiliation” attribute
login id in active directory => Affiliated user
Policy implication login = membership
Problem for edge cases (Distance learning, NHS staff)
• Echo the affiliation
<SimpleAttributeDefinition id=“urn:thing:
eduPersonAffiliation">
<DataConnectorDependency requires="echo"/>
</SimpleAttributeDefinition>
Complex example
• Restricted access to online medical videos
Autopsy videos Medic only
• Duplicate Athens medic restricted group
Manually provisioned by medical librarians
• Problem identifying medics
Students = on medical courses,
identify diversity of courses
keep up to date
Staff = convince medical librarian they are a medic
Solution only good for students
• Long term solution = Grouper?
Complex example
<SimpleAttributeDefinition id="urn:mace…..:eduPersonEntitlement“
sourceName="sdssentitlement“
smartScope=“ncl.ac.uk”>
<DataConnectorDependency requires="db6"/>
</SimpleAttributeDefinition>
<JDBCDataConnector id="db6"
dbURL="jdbc:mysql://thing.ncl.ac.uk/courseData?user=thing&amp;password=thing"
dbDriver="com.mysql.jdbc.Driver“ maxActive="10“ maxIdle="5">
<Query>
SELECT course_code,
CASE course_code
WHEN 'A101' THEN 'urn:mace:ac.uk:thing:entitlelement:emol.sdss.ac.uk:restricted'
WHEN 'A106' THEN 'urn:mace:ac.uk:thing:entitlement:emol.sdss.ac.uk:restricted'
ELSE 'none' END
as
sdssentitlement
</Query>
</JDBCDataConnector>
FROM CMstudentdata WHERE loginid = ?
Lessons Learned – federated use
• Federated attribute usage is a nice well defined simple
subset
• Shibboleth useable with messy composite Identity
Infrastructures
– It is much better not to need to
• Need for identity enrichment tools:
e.g. medical staff
• Shib Technology is not the hard bit
The identity management processes are
Not going to go away
Internal use: What is required
• Access control to internal resources
Valid users - e.g. Exam papers
Group membership - research wikis
• Better usability of applications
Auto population of form fields
Nicer interaction
“Hello Cal” not “Hello ncr18”
• Provisioning of applications
Simple deployment of applications
e.g. Sympa mediawiki
Example: Names sn GivenName
• Need: sn +givenName for Usability
enhancements
e.g. [email protected] vs Caleb Racey, form pre-population
• Problem: Userbase split into staff and students
Data in separate tables
• Solution: Union selects across tables.
• Question: possible if they are in separate DBs?
Example
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:sn">
<DataConnectorDependency requires="db10"/>
</SimpleAttributeDefinition>
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:givenName">
<DataConnectorDependency requires="db10"/>
</SimpleAttributeDefinition>
<JDBCDataConnector id="db10">
<DataConnectorDependency requires="echo"/>
<Query>
SELECT forenames as givenName, surname as sn FROM staff WHERE loginname = ?
UNION
SELECT forenames as givenName, surname as sn FROM student WHERE loginname = ?
</Query>
</JDBCDataConnector>
Future Enhancements
•
Scriptable attribute Aggregation
<DataConnectorDependency requires="directory"/>
<Scriptlet>
<![CDATA[
Attributes attributes =
dependencies.getConnectorResolution("directory");
Attribute affiliation = attributes.get("eduPersonAffiliation");
if (affiliation.size() > 0)
{
resolverAttribute.addValue("affiliate");
}
]]>
</Scriptlet>
Potential Use case: Active Directory Groups
Group membership property of user object
LDAP lookup not easy/possible?
Lessons Learned – internal use
• Attribute aggregation = valuable business process
Expose via webservices?
Duplicate?
Just use shib?
Reengineer identity infrastructure?
• Need identity enrichment tool for future apps
Dspace - identify librarians
Wikis sympa - research groups
Allow Integration of applications into a platform
• Grouper
Enable identity enrichment
Add once, use anywhere
Usability enhancements
• Provide identifiers for self service apps
Library number
Smart card number
Pay role number
• Auto populate forms
Login name
Email address
First name, Surname
• Greater Personal Data visibility
= better integrity?
= higher initial support burden?
Provisioning Applications
Benefits
• Simplifies institutional back ends
AA abstracts business logic
Authentication + authorisation + provisioning in one shot
Reusable between applications
• Enables lightweight deployment techniques
– No more 22,000 user databases
• No Imports, Updates, Suspensions, Removals, Reactivations,
Reprovisioning.
– Fewer deprovisioning headaches
– Application accounts provisioned on first use
– Login deactivated in one place
Provisioning examples
• MediaWiki
PHP based
Install Shibboleth extension
Requires:username (eppn) email address (optional)
Deployed by Graduate in 1st 3 months of job
• Sympa Mailing list manager
Perl based
Requires: Email Address
Configure shibboleth login system
Compatible with legacy (8000 lists)
Media wiki
Sympa
Provisioning Applications: Questions
• Dealing with external users
Separate directory?
Compatible data formats?
Aggrageting multiple identity sources
• User data changes
Change of institute ncr18@ncl becomes ncr18@dur
• Deprovisioning out of scope
Does no login = no problem?
• Lack of data control?
Who is provisioning?
“Freedom of information” requests
• Question: is this any worse than other techniques?
Final Questions?
• Are ARPs usable by users, will they ever be?
• Attribute Aggregation
Deal with messy institutional data stores?
Instigate identity management review?
Enhance identity stores?
Glory in perfect present?
• Provisioning:
Good idea or trouble brewing?