Федерація ПЕАНО

Технічний регламент

1. Вступ

Цей регламент описує технічні вимоги та процедури Федерації ПЕАНО. Він є технічним доповненням до Загальних правил Федерації ПЕАНО. Там, де цей регламент не узгоджується із Загальними правилами, останні мають пріоритет.

2. Термінологія

3. Протоколи, що використовуються

3.1. Технологічний профіль SAML WebSSO Федерації ПЕАНО

Федерація ПЕАНО використовує протокол SAML V2.0 Web Browser SSO Profile [1], який визначає стандарт, що дозволяє IdP та SP створювати і використовувати SSO веб-сервіси на основі SAML.

Для зниження ризиків програмної несумісності рекомендується використовувати програмне забезпечення Shibboleth 2.x [5] але це не є обов'язковим.

3.2. Вимоги до сертифікатів SAML-організацій

Кожна SAML-організація повинна мати сертифікат щоб підписувати та/або зашифрувати SAML-повідомлення. Зазвичай самопідписаний сертифікат створюється за умовчанням під час типової установки програмного забезпечення. Сертифікат є частиною метаданих організації і повинен бути опублікований як частина метаданих Федерації (див. далі).

4. Метадані Федерації

Одним з основних сервісів Федерації є публікація та розповсюдження SAML 2.0 метаданих. Метадані є сукупністю всіх IdP та SP у Федерації, а також деяких технічних елементів, таких як відповідні URL та сертифікати X.509.

4.1. Оприлюднення

Координатор Федерації публікує метадані Федерації. Відповідний URL наведено в розділі Технічна інформація. IdP та SP повинні поновлювати свої копії цих метаданих щонайрідше кожні 24 години.

4.2. Цифровий підпис

Координатор Федерації підписує метадані Федерації перед публікацією. Застосовується сертифікат від УРАН із загальним іменем "PEANO.URAN.UA Metadata Signing Key".

4.3. Надання метаданих організаціями-учасниками

Кожний IdP та SP має свою власну частину метаданих ("метадані організації"), які, як правило, генеруються при установці програмного забезпечення. Щоб направити/відкликати метадані організації до/з Федерації ПЕАНО, звертайтесь на контактну електронну адресу ПЕАНО

5. Схема атрибутів

SAML 2.0 передає посвідчення особи від IdP до SP у формі атрибутів, визначених як схема атрибутів. IdP та SP можуть вільно використовувати будь-які атрибути в будь-якій схемі, що відповідає їх потребам, але, щоб зробити Федерацію дійсно сумісною та інтероперабельною, є вкрай бажаним, щоб IdP був в змозі надавати нижчезазначений набір атрибутів, що базується на таких об'єктних класах і схемах LDAP:

Впровадження інфраструктури IdP не вимагає застосування стандартів LDAP/X.500 повністю. Деякі атрибути можуть генеруватись IdP динамічно на основі значень інших атрибутів.

Розробникам програмного забезпечення рекомендується розробляти надійний програмний код (fail-safe code) із запровадженням запобіжних механізмів на випадок, якщо IdP неспроможний надати атибути, що вимагаються SP.

5.1. Об'єктний клас inetOrgPerson

InetOrgPerson - це об'єктний клас LDAP, стандартизований з метою мати загальну схему персональних даних. Ця схема входить до складу більшості реалізацій каталогів.

5.1.1. givenName

Ім'я кінцевого користувача. Атрибут може опціонально містити комбінацію імені та по-батькові. Допускаються лише літери, дефіси та пробіли.

5.1.2. sn (surname)

Прізвище кінцевого користувача. Допускаються лише літери, дефіси та пробіли.

5.1.3. displayName

Ім'я користувача, яке буде використовуватися при відображенні записів. Оскільки не гарантується, що це значення є постійним і унікальним, не рекомендується його використовувати ні як унікальний ключ бази даних, ні для авторизації.

5.1.4. mail

Адреса персональної електронної пошти користувача (не колективної поштової скриньки!). Необхідна для можливості зв'язатися з кінцевим користувачем.

5.2. Об'єктний клас eduPerson

Об'єктний клас eduPerson визначається як розширення об'єктного класу inetOrgPerson з додаваням до нього атрибутів, притаманних особам з освітнього середовища.

Атрибути eduPersonAffiliation та eduPersonScopedAffiliation мають контрольований словник: вони можуть приймати лише обмежений набір визначених значень. Див. детальніше п. 5.2.1.

Атрибути eduPersonScopedAffiliation та eduPersonPrincipalName є структурованими, що містять в собі значення scope та мають загальний синтаксис: local-part@security-domain, де local-part - частина притаманна конкретному атрибуту, а security-domain (або "Scope") - символьна строка, що співпадає з DNS-доменом організації, відповідальної за IdP. Якщо IdP є власником більш ніж одного DNS-домену, він повинен вибрати один з них і застосовувати його повсякчасно.

5.2.1. eduPersonAffiliation

Цей атрибут зазначає відносини користувача з організацією. Для багатьох застосувань перевірка цього атрибута є достатньою, щоб визначити чи користувач має достатньо прав для доступу до ресурсу. Допустимимии значеннями для eduPersonAffiliation є: faculty, student, staff, alum, member, affiliate, employee, 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:

  1. Алгоримтічний. При цьому, за допомогою певного алгоритму, виходячи з інших атрибутів генерується псевдовипадкове значення або хєш-функція. Такий спосіб має той недолік (для користувача та SP), що значення згенерованого атрибуту буде змінюватись всякий раз, як тільки змінюватимуться атрибути, що є вхідними для задіяного алгоритму. Як наслідок, будь-які персоналізовані дані користувача, такі як збережені пошукові вирази, будуть загублені. Користувач також не матиме можливості змінити або видалити будь-який з попередньо зареєстрованих запитів до системи.
     
  2. Зберігання. Альтернативним рішенням є зберігання всіх будь-коли призначених значень 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.

5.3. Об'єктний клас SCHAC

Схема SCHAC (SCHema for ACademia) має на меті визначати загальні схеми в області вищої освіти, сприяти їх поширенню і спрощувати обмін даними між організаціями.

5.3.1 schacHomeOrganization

Символьна строка (з крапками), що співпадає з DNS-доменом організації, відповідальної за IdP.

6. Захист персональних даних при розповсюдженні атрибутів

IdP не повинні розповсюджувати всі атрибути всім SP стосовно всіх кінцевих користувачів. Інформація, що ідентифікує особу, повинна розповсюджуватись виключно при суворій необхідності. Процедура розповсюдження контрольованих атрибутів та мінімального розкриття визначена в GÉANT Data protection Code of Conduct [9].

Для більшості застосувань достатньо використання атрибутів eduPersonScopedAffiliation або eduPersonTargetedID. Оскільки вони не дозволяють ідентифікувати особу, вони не порушують приватності або права на захист персональних даних. Отже, IdP можуть очікувати на те, що за більшості обставин вони будуть надавати один чи обидва ці атрибути.  SP зазвичай мають робити запит на них або на інші атрибути, що не порушують приватність особи. Будь-який обмін eduPersonPrincipalName потребує від обох сторін додаткових заходів для дотримання принципів захисту даних.

7. Посилання

[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

8. Використані джерела

При створенні цього документу використовувались

Окрема подяка Петеру Шоберу (Peter Schober), ACOnet (Austrian Academic Computer Network) за консультації та обговорення при підготовці цього документа.