1 / 24

eduGAIN Operator Training: Policy and Data Protection Considerations for Federations

This training session, held in Vienna on October 17-18, 2011, focused on the eduGAIN federation policy framework and its impact on data protection and trust within federations. Attendees learned about the principles of trust between Service Providers (SPs) and Identity Providers (IdPs), including the importance of Level of Assurance (LoA) and the agreed-upon attributes and their semantics. Key topics included privacy mechanisms, security measures, operational rules, and the responsibilities of federation operators. The session emphasized the need for a federation policy and the benefits of maintaining a low basic level of trust while allowing for higher optional trust profiles.

thanos
Download Presentation

eduGAIN Operator Training: Policy and Data Protection Considerations for Federations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. eduGAIN federation operatortrainingeduGAIN policy eduGAIN training in Vienna 17-18 Oct 2011 Mikael.linden@csc.fi

  2. Outline • Background • eduGAIN PolicyFramework • Data protectionissues and the data protectiongoodpracticeprofile

  3. Federation is allabouttrust • SP needs to trust the IdP • LoA:quality of identities and authenticationare as agreed • Schema: attributes and theirsemanticsare as agreed • IdPneeds to trust the SP • Privacy: That the SP doesnotinfringe the privacylaws • Everyoneneeds to trust the federation operator • Security: Operationsaredonesecurely • Rules: Operationsfollow the federation rules • Theseissuesarecovered in the federation policy (agreement) • No federation policy => no federation • c.f. PEER, a pure SAML metadata deliveryservice

  4. Startingpoint for eduGAIN interfederationservice • Heterogenious national federations • Sectorscovered: universities, researchinstitutions, schools… • Level of Assurance (LoA): reliability of identities/authentication • Attributes. Recommendedattributes. Semantics (ePAffiliation) • Privacymechanisms: attribute release policies, consentmodules • Incidenthandlingmechanisms • Liability, indemnification, othertypicalcontractualissues • eduGAIN didn’twant to make the national federations to changepolicies • Wouldhavecausedtoomuchtrouble/hallse for the federations

  5. eduGAIN’sapproach • Keep the barlow for federations to join • Don’texcludeanyone • Keep the basiclevel of trustlow • Introduceoptionalprofiles for higherlevels of trust • Data protection • Level of Assurance Policy of Fed1 eduGAINbasiclevel Policy of Fed 3 Policy of Fed 2

  6. And the resultwas • Interfederation, notconfederation • eduGAIN is mostly a metadata exchangeservice • IdPs and SPsareboundonlybytheirnational federation’spolicy • Anycomplaintsabout an IdPor SP willbecoveredlocally in its home federation • Side effect: Provider in fed 1 doesn’tnecessarilytrustprovider in fed 2 • opt-inneededbyEntities SP IdP SP IdP SP IdP IdP SP IdP SP IdP SP SP IdP SP SP SP SP SP SP IdP SP

  7. Opt-in for Entities • ”Uplink”: Entityopts in for beingexposed to eduGAIN • ”Downlink”: EachpeerEntitydecidesifitwants to on-board the metadata of an entitythathasbeenexposed to eduGAIN • IdPneeds to consider the privacyrisks of releasingPersonal Data to foreignSPs • SP needs to considerLoA and attributesemantics of foreignIdPs • Everyoneneeds to consideriftheyarehappywith the peerProvider’s federation agreement

  8. eduGAIN policyframework

  9. eduGAIN Constitution(NREN PC approves/changes) refers to is supplemented by Profiles, required(NREN PC approves/changes) Policy Declaration(signed by Federation 1) Profiles, required(NREN PC approves/changes) Policy Declaration(signed by Federation 2) Policy Declaration(signed by Federation 3) Profiles, recommended(TSG approves/changes) Profiles, recommended(TSG approves/changes) Profiles, optional(TSG approves/changes) Profiles, optional(TSG approves/changes) eduGAIN policyver 1.0 www.edugain.org/policy 1. PolicyDeclaration 2. Constitution 3. Metadata Terms of Accessand Use Seealso: Introduction to the eduGAIN policyframework Profiles: 4. Metadata profile (MUST) 5. WebSSOprofile (MAY) 6. Attributeprofile (SHOULD) 7. Data protectiongoodpracticeprofile (MAY)

  10. 1. eduGAIN Declaration • Cannotbechangedlater • Twopages of text • Joining federation signs and presents to OperationalTeam (OT) • Essentialissues of the policy • Metadata exchange • Entitiesareboundbytheirlocal federation policiesonly • No new legalrightsorobligations for Entities (e.g. liabilities)

  11. 2. Constitution • Goal of eduGAIN • ”to support NREN constituencybyinterfederationservice” • Bodies • NREN PC, GEANT EXEC, Technicalsteeringgroup, OT • Requirements and process for joining • Policyviolation • Branding and trademarks • Quality of identities and attributes • disputeresolution for useridentities, freshness of attributes • Audits for Entities and federations (none) and eduGAIN operations

  12. 3. Metadata Terms of Use <!— Use of this metadata is subject to the Terms of Use at http://www.edugain.org/policy/metadata-tou_1_0.txt --> • URL Attached to allpublished eduGAIN metadata • ”license” agreement of the metadata file • Secondary; participantfederations’ policiesoverridethis • ”use at yourownrisk”

  13. 4. SAML2 Metadata profile (MUST) • MUST: <mdrpi:PublicationInfo> • MUST: publisher • MUST: <mdrpi:UsagePolicy> with a link to Metadata ToU • SHOULD: creationInstant or publicationID • <md:EntityDescriptor> elements • MUST: <md:ContactPerson> with contactType="technical“ • MUST: <md:EmailAddress> • MUST: <mdrpi:RegistrationInfo> • MUST: registrationAuthority • SHOULD: registrationInstant, <mdrpi:RegistrationPolicy> • SHOULD: <md:Organization> with English and native values: • <md:OrganizationName>,<md:OrganizationDisplayName>,<md:OrganizationURL>

  14. 4. SAML2 Metadata profile (c’d) • If <md:EntityDescriptor> contains <md:IDPSSODescriptor> or <md:AttributeAuthorityDescriptor> or <md:SPSSODescriptor> • SHOULD: <mdui:DisplayName> and <mdui:Description> in English and native language(s) • If <md:EntityDescriptor> contains <md:SPSSODescriptor> • MAY:<md:AttributeConsumingService> • Aggregated <md:EntityDescriptor> • SHOULD: <mdrpi:PublicationPath> • MUST: Conformance to SAML V2.0 Metadata Interoperability Profile

  15. 5. WebSSOprofile (OPTIONAL) ”Currently, the only allowed SAML 2.0 protocol profile to be used for Web Single Sign-on in eduGAIN is saml2int (ver 0.2) ”

  16. 6. Attributeprofile (SHOULD) • RECOMMENDED attributes: displayName, common name, mail, eduPerson(Scoped)Affiliation), schacHomeOrganization and schacHomeOrganizationType • At leastoneschacHomeOrganizationType SHOULD befrom international vocabularyurn:mace:terena.org:schac:homeOrganizationType:int • MUST: eP(S)A vocabulary: member,faculty,student,alum,affiliate,library-walk-in • Semantics as defined by REFEDS comparison ver 0.13 • SAML2 persistent ID is RECOMMENDED as the unique ID • Placed in SAML assertion’ssubject/nameIDelement and attributestatement

  17. Data protectionissues and 7. Data protectiongoodpracticeprofile (OPTIONAL)

  18. eduGAIN Data protectiongoodpracticeprofile (DP profile) • EU Data protectiondirective: The IdPtakes a legalriskwhenitreleasespersonal data (PII) to the SP • eduGAIN DP profileuses SAML2 metadata to mediateSP’sprivacyrelatedproperties to the IdP in a structuredway • <RequestedAttribute> element • <mdui:privacyStatementURL> element • New <mddp:Category> and <mddp:LegalGrounds> elements • IdPuses the elements • to decideifattributescanbereleased to the SP • to fulfillitsrelatedobligations • For details, see the full DP profile in www.edugain.org/policy

  19. eduGAIN Data protectionprofile: 1/4: Twokinds of SPs • Categorynon-PII: SP receives no personal data • eduPersonAffiliation, schacHomeOrganization… • Data protectionlawsnotapplied • Category PII: SP receivespersonal data • eduPersonPrincipalName, mail, CN… • Data protectionlawsapplied • SAML2 metadata indicates the SP’scategory: <SPSSODescriptor> <md:Extensions> <mddp:DataProtectionProperties> <mddp:Category>PII</mddp:Category> </mddp:DataProtectionProperties> </md:Extensions>

  20. eduGAIN Data protectionprofile:2/4: Relevance of attributesreleased • Data protectionlaws: attributes an SP receivesmustbeadequate, relevant and not excessive in relation to the purpose of the SP • The IdP must not release attributes the SP does not need • SP’s SAML metadata indicates the attributes the SP declares relevant for its needs <SPSSODescriptor> <AttributeConsumingService ...> <RequestedAttribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri“ Name="urn:oid:2.5.4.4" isRequired="true"/> <RequestedAttribute • NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri“ • Name="urn:oid:2.5.4.42" isRequired="false"/>  </AttributeConsumingService>

  21. eduGAIN Data protectionprofile:3/4: Legal grounds • Data protectionlaws: releasingattributes to an SP is based on either • User’sconsent, or • Necessity (for performing a contract, for performing a taskcarried out in the publicinterest, for legitimateinterests…) • SP proposes the legalgrounds in SAML 2.0 metadata • If the legalgrounds is consent, the IdPasks the user to consent to the attribute release (cf. Consentmodulessuch as uApprove) <SPSSODescriptor> <md:Extensions>     <mddp:DataProtectionProperties>    <mddp:LegalGrounds>consent</mddp:LegalGrounds>    </mddp:DataProtectionProperties> </md:Extensions> In July, 2011 The WP29 Data ProtectionWorkingParty of EU publisheditsopinion on Consent. Relatedmodifications to the profile arebeingdrafted.

  22. eduGAIN Data protectionprofile:4/4: Informing the data subject • Whenreleasingpersonal data to the SP, the data controllermusttell the enduser • Whatpersonal data willbereleased, to whom and for whatpurposes, etc • SP placesitsprivacypolicy URL to its SAML metadata’s MDUI element • The IdPprovides the link to the user (e.g. when s/he consents to attribute release) <SPSSODescriptor> <md:Extensions> <mdui:UIInfo> <mdui:PrivacyStatementURLxml:lang="en"> http://www.example.org/privacypolicy.html        </mdui:PrivacyStatementURL>     </mdui:UIInfo>  </md:Extensions>

  23. Luckily, the level of security is relative to the risks • the controller must implement appropriate technical and organizational measures to protect personal data... • ... such measures shall ensure a level of security appropriate to the risks represented by the processing and the nature of the data to be protected. • Mostcollaborationservices (wikis…) need just CN, mail and ePTID SAML assertionCN, mail, ePTID IdP SP

  24. Futurepolicywork • GN3 projectasked eduGAIN task to prepare an updatedConstitution • To find a long-termsolution to the governancemodel • Level of Assurance issues • Strongidentity, strongauthentication…? • c.f. REFEDS workitem ref6 • C.f. NIST 800-63, inCommonbronze/silver • Currentlylooking at Kantara IAF (LoA 1 and 2?) • Data protectionissues • Joinedforceswith REFEDS attribute release WG • Supporting eduGAIN Data ProtectionGoodPracticeProfile in IdP-sideimplementations

More Related