HEAL-Link Federation Higher Education & Research. Exhibit 2. Technical Specifications & Attribute Specifications

Transcription

1 HEAL-Link Federatin Higher Educatin & Research Exhibit 2 Technical Specificatins & Attribute Specificatins

2 Trust Relatinship Trust relatinship amng the federatin, federatin members and federatin partners is based n X.509 Public Key Infrastructure (PKI) technlgy, which enables mutual authenticatin. This is based n use f the SSL/TLS prtcl and XML digital signatures using keys cntained in X.509 certificates, cnventinally btained frm Certificatin Authrities (CAs) that are recgnized by HEAL-Link Federatin. Cncerning the use f cmmercial Certificate Authrities fr federatin members shuld nt be the nly slutin. Mst f the federatin members have their wn Certificate Authrities due t varius services they prvide t their members. These CAs are acting accrding t service requirements set by the academic cmmunity. Besides that, there is a big cst in retrieving the certificates frm a cmmercial Certificate Authrity. Therefre, HEAL-Link Federatin will take int accunt the plicies f the mentined Certificatin Authrities and integrate them int the list f trusted Certificate Authrities. Digital Certificates HEAL-Link Federatin; Certificate Rles The prtcls and prfiles used by the federatin make extensive use f X.509 certificates t carry the public keys used fr varius purpses. These certificates can be brken dwn int tw main classes: Brwser-facing certificates are visible nly t a user s brwser. Certificates frm any certificatin authrity (CA) may be used here; the main cnstraint being that the CA is accepted as trusted by the user s brwser. The brwser-facing certificates are: The identity prvider s SSL server certificate seen by brwsers (fr example, n a user lgin page). The service prvider s SSL server certificate seen by brwsers (fr example, n actual site pages being prtected by Shibbleth and at assertin cnsumer service endpints). Any SSL server certificates seen by brwsers during the discvery prcess (fr example, n lcal WAYF servers r at institutinal prtals). Trust fabric certificates are visible nly t the identity prvider and service prvider sftware; the user s brwser never sees them. Only certain certificate prducts are acceptable fr this purpse; see belw. The trust fabric certificates are: The certificate fr the identity prvider s XML signing key pair fr SAML services. The certificate fr the identity prvider s SSL server key pair fr SAML services.

3 The certificate fr the service prvider s SSL client key pair fr SAML services. The certificate fr the service prvider s XML signing key pair fr SAML requests. Sftware set-up is simplest when it is pssible t chse the same certificate fr use in all rles fr a given entity. In this case, the brwser-facing certificates and trust fabric certificates are cmbined. Attribute Specificatins The AAI Attribute Specificatin is very imprtant fr the exchange f data amng HEAL- Link Federatin and Federatin Participants. This dcument standardizes the attributes amng all participating rganizatins. The frmat f the attribute definitin is clse t the LDAP syntax. This specificatin started with a basic set f attributes and is based n wrk f [Internet2] fr the [edupersn] specificatin. The set f attributes might get further extended in future versins, depending n attribute requirements f cnsumers (the resurces) and the pssibilities f the attribute prviders (the hme rganizatins) t supply them. The hme rganizatin administratr's and resurce wner's mst imprtant duty regarding attributes is the respect f privacy and data prtectin. Users perceive many f the attributes specified in this dcument as very sensitive infrmatin All peple getting in tuch with these attributes must fully respect user privacy and the relevant data prtectin laws and regulatins which define hw t deal with persnal data. Revealing attribute values can be a security risk. A gd example t shw that aspect is the unique identifier 'uid'. It culd prvide valuable infrmatin t a malicius third party. Its intended semantics is t be a user's identifier fr authenticatin (aka lgin), pssibly als n the hme rganizatin. It is thus security sensitive and hme rganizatin administratrs shuld pnder carefully the decisin t release the uid attribute t any resurce, even within their rganizatin. Cnversely, resurce administratrs shuld nt require the uid attribute unless they have a bilateral agreement with the hme rganizatin administratrs. Nte that Shibbleth is designed t nt release the credentials used fr the authenticatin at the hme rganizatin. Whenever infrmatin is handed ut t third parties, the security risk invlved must be carefully cnsidered. Hme Organizatins and Attributes Hme rganizatins cllect and maintain the infrmatin, which shuld be made available thrugh attributes. It is stred in a user directry, which can either be implemented using an LDAP cmpatible directry (e.g. OpenLDAP r Active Directry) r an SQL database. The hme rganizatin is respnsible fr prper identity management and up-t-date persnal data. In

4 additin, it is als respnsible fr prper cnfiguratin f the Shibbleth Attribute Release Plicy (ARP) defining which attributes may be released t which resurces in rder t prtect the privacy f its users. Each hme rganizatin participating in HEAL-Link Federatin has t implement at least the mandatry attributes as they are defined in this dcument. Resurce Owners and Attributes The set f attributes needed by a resurce depends n the service it ffers t its users. The set may be minimal fr annymus services and rather large fr highly persnalized services with granular authrizatin. One thing that shuld be fllwed is that: accrding t the data prtectin principles, as few as pssible persnal data shuld be prcessed! In additin, a resurce wner shuld carefully cnsider which infrmatin t stre acrss user sessins. The less infrmatin is stred, the smaller impact a ptential misuse has in case f an incident. S it is the duty f the resurce wner t specify which attributes are really required t ffer the service and which additinal desired attributes might allw him/her t ffer ptinal advanced services. When defining their attribute requirements, resurce wners shuld always check the attribute implementatin status f HEAL-Link Federatin. If a resurce requires an attribute nt (yet) implemented in the hme rganizatin f its prspective users, these users will nt be able t access the resurce. Therefre in case f an update at their required attributes, resurce wners shuld ntify HEAL-Link Federatin in due time, in rder fr the prper actin t be taken fr the implementatin f the new attribute. The minimal requirements fr users f HEAL-Link Federatin in attributes are described belw. Mandatry Attributes fr HEAL-Link Federatin Participants Entitlement (edupersnentitlement) Descriptin URI (either URL r URN) that indicates a set f rights t specific resurces. A simple example wuld be a URI fr a cntract with a licensed resurce prvider. When a principal's hme institutinal directry is allwed t assert such entitlements, the business rules that evaluate a persn's attributes t determine eligibility are evaluated there. The target resurce prvider des nt learn characteristics f the persn beynd their entitlement. The trust between the tw parties must be established ut f band. One check wuld be fr the target resurce prvider t maintain a list f subscribing institutins. Assertins f entitlement frm institutins nt n this list wuld nt be hnred. This attribute is suitable when a hme rganizatin knws t which resurces a

5 certain set f their students, staff etc. shuld have access t. The hme rganizatin knws their users and can therefre add a specific entitlement value t the entries f entitled users. Permissible values Typical usage Origin urn:mace:dir:entitlement:shared:cmmn-lib-terms authrizatin [edupersn] OID LDAP syntax Directry String Optinal Attributes fr HEAL-Link Federatin TargetedID (edupersntargetedid) Descriptin A unique identifier fr a persn, mainly fr inter-institutinal user identificatin n persnalized services. Semantics <unique-lcal-id> (lcal part) It is an ID uniquely allcated by the hme rganizatin fr a user that has been authenticated accrding t the lcal authenticatin plicy. It has t be unique. It MAY NOT be reassigned, als if the frmer user left the hme rganizatin. A hme rganizatin has t be able t identify the persn matching that <unique-lcal-id>. TargetedID shuld nt be expsed t end users; especially require a user t prvide it manually. Typical usage Persnalizatin, authrizatin Origin [edupersn] OID

6 LDAP Syntax Directry String Ntes It MUST NOT exceed 256 characters in length. This Dcument is based n the crrespnding dcuments f JISC (UK federated access management) and SWITCHaai (Authenticatin and Authrizatin Infrastructure AAI Federatin, Switzerland).