Tech Track: Attribute Delivery Newcastle University

1. Tech Track: Attribute Delivery Newcastle University Caleb Racey Caleb.Racey@ncl.ac.uk

2. Overview • Introduction • Attribute Issues • External site access • Internal site access • Provisioning • Usability improvements • Roundup

3. 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

4. What attributes are used for • Access control to external applications • federated use • Access control to internal applications • Provisioning internal applications • Usability internal enhancements

5. 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

6. 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

7. 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?

8. 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>

9. Attribute Acceptance • Map attribute to server variables (Header=) • Flexibility useful for supporting legacy e.g. • Map ncr18 to REMOTE_USER for legacy .htaccess • Map ncr18@ncl.ac.uk 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>

10. Attribute acceptance AAP.xml <AttributeRule Name="urn:mace:dir:attribute-def:eduPersonAffiliation" Header="Shib-EP-UnscopedAffiliation" Alias="unscoped-affiliation"> <AnySite> <Value Type="regexp"> ^[M|m][E|e][M|m][B|b][E|e][R|r]$ </Value> </AnySite> </AttributeRule>

11. 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

12. 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>

13. 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?

14. 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 sdssentitlementFROM CMstudentdata WHERE loginid = ? </Query> </JDBCDataConnector>

15. 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

16. 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

17. Example: Names sn GivenName • Need: sn +givenName for Usability enhancements • e.g. ncr18@ncl.ac.uk 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?

18. 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>

19. 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?

20. 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

21. 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?

22. 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

23. 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)

24. Media wiki

25. Sympa

26. 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?

27. 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?