Цей регламент описує технічні вимоги та процедури Федерації ПЕАНО. Він є технічним доповненням до Загальних правил Федерації ПЕАНО. Там, де цей регламент не узгоджується із Загальними правилами, останні мають пріоритет.
Федерація ПЕАНО використовує протокол SAML V2.0 Web Browser SSO Profile [1], який визначає стандарт, що дозволяє IdP та SP створювати і використовувати SSO веб-сервіси на основі SAML.
Для зниження ризиків програмної несумісності рекомендується використовувати програмне забезпечення Shibboleth 2.x [5] але це не є обов'язковим.
Кожна SAML-організація повинна мати сертифікат щоб підписувати та/або зашифрувати SAML-повідомлення. Зазвичай самопідписаний сертифікат створюється за умовчанням під час типової установки програмного забезпечення. Сертифікат є частиною метаданих організації і повинен бути опублікований як частина метаданих Федерації (див. далі).
Одним з основних сервісів Федерації є публікація та розповсюдження SAML 2.0 метаданих. Метадані є сукупністю всіх IdP та SP у Федерації, а також деяких технічних елементів, таких як відповідні URL та сертифікати X.509.
Координатор Федерації публікує метадані Федерації. Відповідний URL наведено в розділі Технічна інформація. IdP та SP повинні поновлювати свої копії цих метаданих щонайрідше кожні 24 години.
Координатор Федерації підписує метадані Федерації перед публікацією. Застосовується сертифікат від УРАН із загальним іменем "PEANO.URAN.UA Metadata Signing Key".
Кожний IdP та SP має свою власну частину метаданих ("метадані організації"),
які, як правило, генеруються при установці програмного забезпечення.
Щоб направити/відкликати метадані організації до/з
Федерації ПЕАНО, звертайтесь на контактну електронну адресу ПЕАНО
SAML 2.0 передає посвідчення особи від IdP до SP у формі атрибутів, визначених як схема атрибутів. IdP та SP можуть вільно використовувати будь-які атрибути в будь-якій схемі, що відповідає їх потребам, але, щоб зробити Федерацію дійсно сумісною та інтероперабельною, є вкрай бажаним, щоб IdP був в змозі надавати нижчезазначений набір атрибутів, що базується на таких об'єктних класах і схемах LDAP:
Впровадження інфраструктури IdP не вимагає застосування стандартів LDAP/X.500 повністю. Деякі атрибути можуть генеруватись IdP динамічно на основі значень інших атрибутів.
Розробникам програмного забезпечення рекомендується розробляти надійний програмний код (fail-safe code) із запровадженням запобіжних механізмів на випадок, якщо IdP неспроможний надати атибути, що вимагаються SP.
InetOrgPerson - це об'єктний клас LDAP, стандартизований з метою мати загальну схему персональних даних. Ця схема входить до складу більшості реалізацій каталогів.
5.1.1. givenName
Ім'я кінцевого користувача. Атрибут може опціонально містити комбінацію імені та
по-батькові. Допускаються лише літери, дефіси та пробіли.5.1.2. sn (surname)
Прізвище кінцевого користувача. Допускаються лише літери, дефіси та пробіли.
5.1.3. displayName
Ім'я користувача, яке буде використовуватися при відображенні записів. Оскільки не гарантується, що це значення є постійним і унікальним, не рекомендується його використовувати ні як унікальний ключ бази даних, ні для авторизації.
5.1.4. mail
Адреса персональної електронної пошти користувача (не колективної поштової скриньки!). Необхідна для можливості зв'язатися з кінцевим користувачем.
Об'єктний клас eduPerson визначається як розширення об'єктного класу inetOrgPerson з додаваням до нього атрибутів, притаманних особам з освітнього середовища.
Атрибути eduPersonAffiliation та eduPersonScopedAffiliation мають контрольований словник: вони можуть приймати лише обмежений набір визначених значень. Див. детальніше п. 5.2.1.
Атрибути eduPersonScopedAffiliation та eduPersonPrincipalName
є структурованими, що містять в собі значення scope та мають загальний
синтаксис:
5.2.1. eduPersonAffiliation
Цей атрибут зазначає відносини користувача з організацією. Для багатьох застосувань перевірка цього атрибута є достатньою, щоб визначити чи користувач має достатньо прав для доступу до ресурсу. Допустимимии значеннями для eduPersonAffiliation є: faculty, student, staff, alum, member, affiliate, employee,
library-walk-in. Семантика цих значень описана нижче.
- faculty
Така категорія призначається викладачам або дослідникам (науковцям).
- staff
Така категорія призначається працівникам, що не є викладачами або дослідниками, таким як адміністративний, технічний або допоміжний персонал.
- employee
Ця категорія призначається будь-якій особі, що працює в організації, включаючи faculty та staff, а також підрядникам, практикантам, волонтерам тощо. (Відмінності у визначенні термінів staff та employee в різних країнах є часто взаємно-суперечливими, тому їх розрізнення в будь-якому міжнародному контексті є вкрай ненадійним.)
- student
Така категорія призначається студентам, аспірантам та іншим слухачам системи післядипломної освіти.
- member
Така категорія включає в себе викладачів, співробітників, студентів та інших осіб, що мають базовий набір прав, які витікають із належності до університетської спільноти (наприклад, вони мають доступ до бібліотеки, володіють VPN акаунтом в мережі тощо). Ця категорія повинна призначатись особам, яким призначена хоча б одна з наступних категорій: faculty, staff, employee або student.
- alum
Така категорія призначається колишнім студентам навчального закладу. Її допустимо призначати також і тим особам, що не завершили курс навчання. Особа такої категорії зазвичай не є member, оскільки не має доступу до повного набору прав в навчальному закладі, на відміну від faculty, staff або student.
- affiliate
Особа, яка віднесена до такої категорії, має певне відношення до університету, але вона не підпадає під жодну категорію faculty, staff, student, alum та/або member. Типовими прикладами є волонтери на різних подіях та заходах, батьки студентів, гості, зовнішні перевіряючі тощо. Визначення цієї категорії значно варіюється поміж різних навчальних закладів.
- library-walk-in
Ця категорія ("відвідувач бібліотеки") була створена, щоб охопити випадок, коли фізична присутність особи в приміщенні бібліотеки надає їй можливість доступу до електронних ресурсів, на які, як правило, придбана ліцензія для викладачів, співробітників і студентів. В останні роки поняття "відвідувач бібліотеки" поширюється на інші випадки, зокрема на користувачів бібліотеки в режимі он-лайн з кампусової мережі або користувачів кампусових робочіх станцій. Постачальники ліцензованих ресурсів часто готові інтерпретувати свої контракти з ліцензіатами, погоджуючись з таким широким тлумачення терміну "відвідувач бібліотеки", хоча конкретні умови можуть бути різними.5.2.2. eduPersonScopedAffiliation
Цей атрибут дозволяє організації заявляти про свої відносини з користувачем. Він призначений для найпоширенішого випадку, коли он-лайн ресурс надається на основі ліцензії, і єдиною умовою для надання доступу є вимога, щоб користувач був членом організації або її певного підрозділу (школи, факультету тощо).
Цей атрибут багатозначний (тобто користувач може мати більш ніж одне значення цього атрибуту) і структурований у формі
affiliation@security-domain , де affiliation - одна з призначених категорій, що зазвичай зберігається в eduPersonAffiliation (див. п. 5.2.1), аsecurity-domain (або "Scope"), як описано вище, - символьна строка, що співпадає з DNS-доменом організації, відповідальної за IdP, чиє значення зазвичай зберігається в schacHomeOrganization (див. п. 5.3.1).Деякі значення eduPersonScopedAffiliation розглядаються як такі, що знаходяться "всередині" інших значень: наприклад, категорія student охоплюється категорією member. Рекомендується, щоб IdP мали можливість або утримувати обидві категорії для такої особи, або ж мали змогу розповсюджувати те з двох значень, яке відповідає потребам конкретного SP. Наприклад, деякі SP могли б вимагати підтвердження їм вузької категорії student. В той же час тим із SP, хто потребує підтвердження більш широкої категорії member, не слід передавати значення вузької категорії: розповсюдження student в цьому випадку давало б SP більше інформації про користувача, ніж вимагається, і тим самим порушувало би приватність користувача та його право на нерозголошення персональних даних.
На відміну від рекомендації, щоб IdP були консервативнішими в плані того, що вони передають, SP мають бути більш ліберальним у плані того, що вони визнають прийнятним. Наприклад, SP, що вимагає підтвердити категорію member, слід також задовольнятись student, staff тощо як альтернативами.
5.2.3. eduPersonTargetedID
Якщо в SP пред'явлена лише категорія анонімного користувача eduPersonScopedAffiliation, SP не зможе надати персоналізованого сервісу або здійснювати моніторинг користувача від одного сеансу до іншого. Таке стає можливим завдяки атрибуту eduPersonTargetedID, який містить постійний псевдонім користувіача, що використовується спільно IdP та SP, причому для різних SP використовуються різні псевдоніми. IdP використовує відповідне значення цього атрибута при спілкуванні з конкретним SP і не розголошує цього значення іншим SP.
SP може використовувати eduPersonTargetedID з метою підтримки тих аспектів його сервісу, які залежать від розпізнавання користувача від одного його сеансу до іншого. Найбільш загальне використання - це можливість персоналізації сервіса з метою зберігання вподобань користувача (наприклад, збережених пошукових виразів) між його сеансами. Інше використання - моніторинг активності користувача для фіксації можливих порушень умов ліцензії, наприклад, систематичних завантажень контенту тощо.
Кожному користувачу IdP призначає відмінні значення eduPersonTargetedID для кожного з SP, якому цей атрибут передається. Таким чином, атрибут є багатозначним (з одним значенням для кожного SP), але конкретному SP кожного разу передається одне й те саме значення.
Не вимагається, щоб цей атрибут був придатним для читання людиною. Він створений для захисту приватності користувача і унеможливлення аналізу його активності шляхом встановлення корреляції між сервісами, які він отримує у різних SP. Таким чином, цей атрибут мусить бути непрозорим і таким, що не має зв'язку з іншими ідентифікаторами користувача, зокрема його іменем.
Значення eduPersonTargetedID, одного разу призначене користувачу для певного SP, не повинно ніколи перепризначатись іншому користувачу. Проте не існує правила, щоб користувач назавжди пред'являв одне й те саме значення eduPersonTargetedID. Навпаки, IdP може надавати користувачу можливість згенерувати нові значення eduPersonTargetedID, якщо той відчуває, що його приватність порушено.
Є два способи, у які IdP може впровадити eduPersonTargetedID:
- Алгоримтічний. При цьому, за допомогою певного алгоритму, виходячи з інших атрибутів генерується псевдовипадкове значення або хєш-функція. Такий спосіб має той недолік (для користувача та SP), що значення згенерованого атрибуту буде змінюватись всякий раз, як тільки змінюватимуться атрибути, що є вхідними для задіяного алгоритму. Як наслідок, будь-які персоналізовані дані користувача, такі як збережені пошукові вирази, будуть загублені. Користувач також не матиме можливості змінити або видалити будь-який з попередньо зареєстрованих запитів до системи.
- Зберігання. Альтернативним рішенням є зберігання всіх будь-коли призначених значень eduPersonTargetedID. Коли з'являється потреба в новому значенні, в цій базі даних проводиться перевірка для уникнення дублювань при призначенні. Поточні значення eduPersonTargetedID зберігаються прив'язаними до відповідного користувача. Такий шлях є найбільш надійним для забезпечення обмеження на перепризначення eduPersonTargetedID.
5.2.4. eduPersonPrincipalName
Цей атрибут використовується там, де потребується незмінний єдиний ідентифікатор користувача для доступу до різних сервісів. Він часто відповідає SSO імені користувача і може бути корисним для забезпечення як внутрішних сервісів всередині організації, так і зовнішніх сервісів, де використовуються списки управління доступом (access control lists).
Цей атрибут є однозначним і структурованим у формі
local-name@security-domain . Компонентsecurity-domain (" Scope") має ту ж семантику, як аналогічний компонент в eduPersonScopedAffiliation. Компонентlocal-name повинен бути унікальним в контекстіsecurity-domain .Значення eduPersonPrincipalName, що раніше було присвоєне одній особі, ніколи більше не повинно призначалось іншій особі. В той же час, як і у випадку eduPersonTargetedID, користувачі та SP мають знати, що IdP можуть перепризначити особі інше значення eduPersonPrincipalName.
5.2.5. eduPersonEntitlement
Цей атрибут дає організації змогу стверджувати, що користувач задовольняє додатковому набору особливих умов, що застосовується для доступу до певного ресурсу. Користувач може мати декілька різних значень атрибута eduPersonEntitlement, кожний для свого ресурсу, тому IdP мусять підтримувати цей атрибут як багатозначний.
Значенням eduPersonEntitlement є URI (URL або URN), що зазначає набір прав стосовно певного ресурсу. Наприклад: "http://publisher.example.com/contract/GL123" або "urn:mace:washington.edu:confocalMicroscope". Простим прикладом може слугувати URL на контракт з SP, що надає доступ до ліцензованого ресурсу.
Сенс кожнго значення eduPersonEntitlement зазвичай визначається самим SP. У випадку використання URL-схеми рекомендується, щоб значення цього атрибуту було посиланням на документ, в якому дається пояснення цього значення.
Після визначення сенсу, який вкладається в значення атрибута, SP пропонує деяким або всім IdP надавати це значення тим користувачам, які задовольняють визначенню. У такий спосіб SP може делегувати в IdP частину або всю відповідальність за авторизацію доступу до свого ресурсу. Тим самим SP довіряє IdP самостійно перевіряти, чи відповідає користувач умові авторизації (яка в загальному випадку може бути як завгодно складною), що пов'язана з правом доступа до цього ресурсу. Часто в ліцензійну угоду включається додатковий пункт, згідно з яким організація, відповідальна за IdP, бере на себе зобов'язання призначати значення eduPersonEntitlement у відповідності до узгодженого критерія.
Проте, сам факт наявності прав доступу до особливого ресурсу може являти собою персональні дані користувача, причому, навіть, вельми чутливі дані. Таким чином, важливо прискіпливо контролювати розповсюдження індивідуальних значень eduPersonEntitlement, щоб його отримував тільки SP з обґрунтованою необхідністю певного значення eduPersonEntitlement. Наприклад, значення, визначені певним SP, за нормальних умов повинні передаватись лише назад цьому ж SP.
Схема SCHAC (SCHema for ACademia) має на меті визначати загальні схеми в області вищої освіти, сприяти їх поширенню і спрощувати обмін даними між організаціями.
5.3.1 schacHomeOrganization
Символьна строка (з крапками), що співпадає з DNS-доменом організації, відповідальної за IdP.
IdP не повинні розповсюджувати всі атрибути всім SP стосовно всіх кінцевих користувачів. Інформація, що ідентифікує особу, повинна розповсюджуватись виключно при суворій необхідності. Процедура розповсюдження контрольованих атрибутів та мінімального розкриття визначена в GÉANT Data protection Code of Conduct [9].
Для більшості застосувань достатньо використання атрибутів eduPersonScopedAffiliation або eduPersonTargetedID. Оскільки вони не дозволяють ідентифікувати особу, вони не порушують приватності або права на захист персональних даних. Отже, IdP можуть очікувати на те, що за більшості обставин вони будуть надавати один чи обидва ці атрибути. SP зазвичай мають робити запит на них або на інші атрибути, що не порушують приватність особи. Будь-який обмін eduPersonPrincipalName потребує від обох сторін додаткових заходів для дотримання принципів захисту даних.
[1]
Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0.
OASIS Standard, 15 March 20055
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
[2]
SAML V2.0 Metadata Interoperability Profile Version 1.0.
Committee Specification 01, 4 August 2009
http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop.pdf
[3]
Interoperable SAML 2.0 Profile
http://saml2int.org
[4]
urn:mace:shibboleth:metadata:1.0
https://svn.shibboleth.net/cpp-sp/branches/Rel_1_3/schemas/shibboleth-metadata-1.0.xsd
[5]
Shibboleth Consortium
http://shibboleth.net
[6]
RFC 2798. Definition of the inetOrgPerson LDAP Object Class.
M. Smith, Internet Engineering Task Force, Apr. 2000, updated by RFCs 3698, 4519, 4524.
http://www.ietf.org/rfc/rfc2798.txt
[7]
eduPerson Object Class Specification
https://www.internet2.edu/products-services/trust-identity-middleware/eduperson-eduorg/eduperson-eduorg-documentation/
[8]
SCHAC, SCHema for ACademia. TERENA.
http://www.terena.org/activities/tf-emc2/schac.html
[9]
GÉANT Data protection Code of Conduct
http://www.geant.net/uri/dataprotection-code-of-conduct/Pages/default.aspxx
При створенні цього документу використовувались
Окрема подяка Петеру Шоберу (Peter Schober), ACOnet (Austrian Academic Computer Network) за консультації та обговорення при підготовці цього документа.