Институционална и централна администрация

Open Manuscript Studio Сега разделя личната академична идентичност, принадлежността към институцията, администрацията на институцията и централната администрация на OMI на отделни нива на оторизация.

Това разграничение е умишлено: административните правомощия не включват достъп до ръкописи, рецензии, редакционни решения или друго научно съдържание. Достъпът до съдържанието продължава да се регулира от моделите за разрешения за ръкописи/работни пространства и за издателския работен процес.

Самолети за оторизация

Личен акаунт в Studio

Акаунтът в Studio представлява постоянна идентичност, която се използва в браузъра, на настолния компютър и в мобилните приложения. Той може да включва парола и методи за федеративно влизане, лична профилна информация, както и едно или повече институционални членства.

Членство на институции

Всяко членство свързва един акаунт в „Студио“ с една институция и включва една от следните три роли:

• MEMBER — обичайна институционална принадлежност;
• ADMIN — администратор на институцията;
• OWNER — собственик на институцията, който има правомощия да извършва промени в ролите на ниво „собственик“.

Споделят се данни за институцията, като например наименованието на организацията и идентификаторът „ROR“. Отделът, длъжността, институционалният имейл адрес, свързаната институционална идентичност и състоянието на принадлежността по подразбиране се отнасят към членството, а не към постоянния личен акаунт.

Един потребител може да принадлежи към няколко институции, като едно от тези членства може да бъде избрано като принадлежност по подразбиране.

OMI централна администрация

Централната администрация се съхранява отделно от членството в институциите. Централният администратор разполага с:

• ADMIN — оперативно управление, обхващащо различни институции;
• OWNER — управление от централния администратор в допълнение към обичайното централно администриране.

Дадена институция OWNER не е автоматично централен администратор, а централният администратор не е автоматично член или собственик на която и да е институция.

Вход за администратори на институцията

При институционалното внедряване може да се активира специален режим за вход за администратори на институцията, като се използва същият акаунт в Studio.

Влизането на администратора с парола се приема само ако удостовереният акаунт разполага с активен абонамент за ADMIN или OWNER.

Влизането на федеративен администратор може да се осъществи чрез конфигурирани доставчици на Google, Microsoft или институционални доставчици на OpenID Connect. След приключване на външното влизане Studio проверява контекста на институционалния администратор на сървъра, преди да приеме административната сесия.

ORCID умишлено не представлява удостоверение за администратор на институция. Идентификаторът „ORCID“ остава личен научен идентификатор и механизъм за установяване на самоличността на автора.

Начално конфигуриране на администратора на институцията

При управляваните институционални внедрявания може да се определи списък с разрешени институции и администратори:

INSTITUTIONAL_NAME=
INSTITUTIONAL_ROR_ID=
INSTITUTIONAL_ADMIN_EMAILS=

Само по себе си включването в списъка с разрешени адреси не дава право на собственост. За автоматичното първоначално създаване на акаунт в OWNER е необходимо съответният акаунт в Studio да има свързана OIDC или SAML идентичност. Акаунти, достъпни само с парола, никога не се преобразуват автоматично.

Зареждане на централния администратор

Първият централен администратор може да бъде стартиран с:

CENTRAL_ADMIN_EMAILS=
INSTITUTION_API_TOKEN_TTL_DAYS=365

Както и при първоначалната настройка на институцията, акаунтът, включен в списъка с разрешени достъпи, трябва вече да разполага с свързана OIDC или SAML идентичност, преди да може да стане първоначален централен „OWNER“.

Това предотвратява ситуация, при която акаунт, достъпен само с парола, или съвпадение на имейл адрес да придобие незабелязано административни правомощия в различни институции.

Възможности на централната администрация

Уебсайтът за централно управление на персонала API е достъпен на адрес /api/central-admin и поддържа:

• контекст на централния администратор;
• списък с институции, създаване, актуализиране, активиране и деактивиране;
• управление от централния администратор (само за OWNER);
• назначаване и освобождаване на администратора на институцията;
• създаване и отмяна на удостоверения от администратора на институцията API;
• извличане на аудиторския журнал на администрацията.

Приложението показва тези елементи за управление в „Настройки на профила“ само за потребители, които разполагат с право за централно администриране.

Тази реализация предпазва последния централен елемент OWNER и последната институция OWNER от случайно премахване или понижаване в йерархията.

Администратор на институцията API

Институциите могат също така да получават машинно генерирани идентификационни данни за целите на автоматизацията. Тези идентификационни данни са свързани с точно една институция и използват изрично определени обхвати.

Токените „Raw“ са в следния формат:

omi_ia_...

Пълният токен се връща само веднъж – при създаването му. Studio съхранява само хеш от типа „SHA-256“, заедно с несекретен префикс за идентификация, състоянието на валидност/отмяна и метаданни за използването.

Първоначалните области на приложение са:

institution:read
members:read
members:write
integrations:read
integrations:write

Първите крайни точки на машините от версия 1 са:

GET   /api/institution-admin/v1/context
GET   /api/institution-admin/v1/members
PATCH /api/institution-admin/v1/members/:membershipId/role

Упълномощенията на машините не могат да присвояват, премахват, повишават или понижават роли в „OWNER“. Промените в собствеността изискват намесата на човек – собственик на институцията или централен администратор.

Обхватите „integrations:read“ и „integrations:write“ определят границите на оторизацията за администриране на интеграцията в рамките на дадена институция. Отделни крайни точки за интеграция могат да се добавят, без да се разширява обхватът на удостоверението извън пределите на съответната институция.

Модел за одит

Административните действия се записват в събития за одит, към които се добавят само нови записи. В зависимост от действието, записът за одит може да включва:

• администратор или институция API;
• институция;
• име на действието;
• тип на целта и идентификатор на целта;
• некласифицирани метаданни за действията;
• IP адресът на клиента, когато е наличен;
• време на създаване.

Паролите, необработените токени от типа „API“, тайните от типа „OAuth“, текстът на ръкописа и тайните на доставчиците не трябва да се записват в аудитния дневник за администриране.

Граници на сигурността

Архитектурата на администрацията се придържа към следните правила:

1. Ролите на институциите и централните роли се съхраняват отделно.
2. Сама по себе си никоя администраторска роля не предоставя достъп до ръкописи или редакционно съдържание.
3. Федеративните идентичности се идентифицират чрез издателя и субекта, а не чрез променливи имена за показване.
4. За първоначалното привилегировано стартиране е необходима свързана OIDC/SAML идентичност, както и списък с разрешени имейл адреси.
5. Токените „API“ на институцията са обвързани с институцията и с конкретен обхват, имат срок на валидност и могат да бъдат отменени, като се съхраняват единствено под формата на хеш-стойности.
6. Машината API не може да променя ролите на собствениците.
7. Защитните мерки на централно ниво и на ниво институция за последния собственик предотвратяват случайно административно блокиране.
8. Административните действия подлежат на одит, без да се съхраняват поверителна информация или научно съдържание.

Връзка с режимите на разгръщане

Един и същ клиентски код на Studio може да работи както в лични, така и в институционални среди. Режимът на разгръщане избира управляваните от сървъра идентификационни данни за външни услуги и интерфейса за институционално администриране; той не променя модела на ръкописа „OMI“ нито преносимостта на документите.

Вижте Studio deployment modes за маршрутизиране на удостоверенията и конфигурация на ниво разгръщане, както и Studio implementation status за актуалната снимка на зрелостта на референтната реализация.