110 likes | 129 Views
SURFfederatie. Klaas Wierenga, EuroCAMP Helsinki, 17&18th April 2007. General intro Status IdM practices/policy Policy enforcement Roles & groups Schemas LoA. Contents. Federation close to production status
E N D
SURFfederatie Klaas Wierenga, EuroCAMP Helsinki, 17&18th April 2007
General intro Status IdM practices/policy Policy enforcement Roles & groups Schemas LoA Contents
Federation close to production status Model with Central Federation Component (CFC) that translates federation protocols on-the-fly (SAML/A-Select/ADFS/ID-FF) Registration at privacy body (temporary storage of user data for FederatedSSO and/or federation protocol translation). NO requirements wrt technology General introduction
Test/Acceptation federation now runs approx. 1.5 jaar IdP's: RUG, UU, SURFnet, TU-Delft RADIUS IdP for eduroam customers, used by: HU, Avans, HvA, Saxion, HAN Pilots with: Elsevier SD, Dutch publishers, Ellips consortium, SURFnet diensten Scheduled: EBSCO, Microsoft, SURFdiensten, OCLC Pica Status
2 parties: FederatieLeden (federation members) Annex to regular contract with SURFnet Low level entry FPartners contract between SURFnet and Partner SURFnet is operator Contracts, attributes that are needed for a service published at website Userboard deputation of federation members IdM practices/policies
Federation Member Sign and you’re member Club-model Weak enforcement Almost no formal rules wrt identity management Some rules wrt privacy, 'good IdM' and dealing with abuse Service Provider MUST sign contract Define service, attributes etc. Privacy regulations (best practice will be made available) Requirements on certificate organisation, hostname, ‘friendly name’ Policy enforcement
None Federation is transparant channel Federation is TTP (signing of certificates of SP's / IdP's) Roles & groups
2 requirements: (opaque)userid@organisation organisation (IdP) Schemas: study in Shibboleth pilot SCHAC IdM at institutions NOT homegeneous Easy start with simple model Presumably 4 or 5 mandatory fields, rest optional Schemas used/planned
Unique selling point of A-Select since version 0.1! Requires authN standardisation in the policy wrt IdM, naming and issuance <authentication_methods> <identifier authsp_id="radius" uri="urn:oasis:names:tc:SAML:1.0:am:password"/> <identifier authsp_id="ldap" uri="urn:oasis:names:tc:SAML:1.0:am:password"/> <identifier authsp_id="sid" uri="urn:oasis:names:tc:SAML:1.0:am:HardwareToken"/ <identifier authsp_id="pki" uri="urn:oasis:names:tc:SAML:1.0:am:X509-PKI"/> Levels of AuthN
More info: http://federatie.surfnet.nl/ Klaas.Wierenga@surfnet.nl Thank you!