Режими на внедряване на студио

Open Manuscript Studio използва една кодова база и едно семейство от уеб, настолни и мобилни клиенти. Профилът за внедряване от страна на сървъра определя кой управлява данните за достъп до външни услуги и дали са активирани интерфейсите за администриране от страна на институцията.

Личен режим

DEPLOYMENT_MODE=personal

Личният режим е предназначен за независими автори и индивидуални потребители. Studio никога не изисква парола за ORCID. Удостоверяването чрез ORCID се извършва на собствената страница за оторизация на ORCID чрез OAuth/OpenID Connect.

Личният режим използва пространството от имена на удостоверенията, управлявано от „Personal/OMI“:

ORCID_CLIENT_ID=APP-...
ORCID_CLIENT_SECRET=...
ORCID_REDIRECT_URI=https://studio.example.org/api/auth/orcid/callback

Целевата архитектура остава OMI, като се осигурява посредничество при идентификацията по ORCID, така че отделните автори да не се налага сами да получават или поддържат ORCID API своите идентификационни данни.

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

DEPLOYMENT_MODE=institutional

Институционалният режим е предназначен за издатели, научни списания, университети, хранилища, изследователски инфраструктури и управлявани инсталации на OJS/OMP. Институцията използва отделно пространство за имена на идентификационни данни, собственост на организацията:

INSTITUTIONAL_ORCID_CLIENT_ID=APP-...
INSTITUTIONAL_ORCID_CLIENT_SECRET=...
INSTITUTIONAL_ORCID_REDIRECT_URI=https://publisher.example.org/api/auth/orcid/callback
INSTITUTIONAL_ORCID_API_TYPE=public

INSTITUTIONAL_ORCID_API_TYPE приема public или member. Секретните данни за интеграция се съхраняват на сървъра и в никакъв случай не трябва да бъдат разкривани чрез паметта на браузъра, променливи при изграждането на фронтенда или конфигурацията от страна на клиента.

При институционалните внедрявания също могат да се дефинират организационната структура и първоначалната настройка на администратора:

INSTITUTIONAL_NAME=
INSTITUTIONAL_ROR_ID=
INSTITUTIONAL_ADMIN_EMAILS=

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

Първоначална настройка и вход за институционалния администратор

Повърхността за вход на администратора на институцията е активирана само когато сървърът работи в институционален режим. Минималната конфигурация за първоначално стартиране е:

DEPLOYMENT_MODE=institutional
INSTITUTIONAL_NAME="Example University Press"
INSTITUTIONAL_ADMIN_EMAILS="admin@example.org"

Ако институцията разполага с идентификатор от типа „ROR“, той също трябва да бъде конфигуриран:

INSTITUTIONAL_ROR_ID="https://ror.org/012345678"

Могат да се посочат няколко адреса на администратори за буутстрап под формата на списък с разрешени адреси, разделени със запетая:

INSTITUTIONAL_ADMIN_EMAILS="admin@example.org,second.admin@example.org"

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

1. имейл адресът на акаунта в Studio трябва да съвпада с адрес, регистриран в INSTITUTIONAL_ADMIN_EMAILS; и
2. Същият акаунт в Studio трябва вече да има свързана идентичност от типа OIDC или SAML.

Самото наличие на локален акаунт с имейл и парола не е достатъчно за автоматичното предоставяне на достъп до OWNER. Това предотвратява ситуация, при която притежаването на локално конфигурирана парола се приема като доказателство за институционален контрол.

Когато администраторът с необходимите права влезе в системата, Studio изпълнява следната поредица от действия от страна на сървъра:

1. удостоверява профила в Studio;
2. проверява конфигурираната институционална политика за начално зареждане;
3. създава записите за институцията, ако те все още не съществуват;
4. създава или надгражда членството на съответната институция до „OWNER“;
5. свързва членството с свързаната федеративна идентичност; и
6. приема сесията на институцията-администратор едва след потвърждаване на активно членство в ADMIN или OWNER.

След това администраторът може да използва режима на влизане „Администратор на институцията“ на страницата за влизане в Studio. За стартиране на този процес на влизане може да се използва удостоверяване чрез имейл/парола, както и конфигурирани OIDC доставчици, но сървърната система винаги извършва проверка на ролята в институцията, преди да предостави административния контекст.

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

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

Изолиране на удостоверенията

Маршрутизирането на удостоверенията е детерминистично и се контролира от DEPLOYMENT_MODE:

• personal използва само ORCID_CLIENT_ID, ORCID_CLIENT_SECRET и ORCID_REDIRECT_URI.
• institutional използва единствено набора от идентификационни данни „INSTITUTIONAL_ORCID_*“.
• Институционалният режим никога не преминава автоматично към данните за достъп, принадлежащи на „Personal“ или „OMI“.
• Ако липсва активният набор от удостоверения, услугата „ORCID“ се отчита като неконфигурирана.
• Двойка частично активни удостоверения води до неуспешна проверка на конфигурацията на сървъра.
• Studio никога не разкрива нито един от тайните ключове на клиента чрез статуса си по време на изпълнение API.

Мрежата „ORCID“ се избира независимо:

ORCID_ENVIRONMENT=sandbox

или:

ORCID_ENVIRONMENT=production

Това позволява безопасно институционално тестване в средата „ORCID Sandbox“ преди пускането в производствена среда.

Вход чрез федеративен акаунт

Студиото може допълнително да предоставя достъп до конфигурирани доставчици на Google, Microsoft, както и до общи/институционални доставчици на OpenID Connect. Те използват потока „Код за оторизация“ с PKCE и валидиране от страна на сървъра на състоянието, nonce, издателя, аудиторията и ключовете за подписване.

Досега неизвестна външна идентичност може да създаде акаунт в Studio, когато доставчикът предостави необходимите потвърдени данни за идентичността. Съществуващ акаунт в Studio не се свързва автоматично само защото доставчикът е посочил същия имейл адрес; свързването изисква изрично действие от страна на потребителя, влязъл в акаунта си.

При влизане в системата като институционален администратор могат да се използват конфигурирани OIDC доставчици, но сървърът все пак проверява дали акаунтът има активно членство в институцията ADMIN или OWNER, преди да бъде приет административният контекст.

ORCID модел за сигурност

Профилът за внедряване не променя правилото за удостоверяване: Studio никога не събира, не предава и не съхранява паролата на потребителя за ORCID. Потребителят се удостоверява директно чрез ORCID, включително чрез двуфакторно удостоверяване, когато то е активирано, а Studio получава само резултата от OAuth/ OpenID Connect.

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

ORCID умишлено не се използва като идентификационна информация за администратор на институция. Той остава личен научен идентификатор и може да се използва в процесите по проверка на самоличността на автора и криптографско подписване.

Профили и роли на институциите

Настоящият модел „Studio Identity“ разделя трайните данни за личния акаунт от членствата, свързани с конкретна организация.

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

• MEMBER;
• ADMIN;
• OWNER.

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

Крайните точки на администраторите на институциите прилагат тези роли от страна на сървъра. Последната институция OWNER е защитена от случайно премахване или понижаване на нивото.

Вижте Institutional and Central Administration за пълния модел на привилегиите и API за модела.

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

Администрирането между институции представлява отделно ниво на привилегии и никога не се извежда автоматично от членството в дадена институция.

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

CENTRAL_ADMIN_EMAILS=
INSTITUTION_API_TOKEN_TTL_DAYS=365

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

Централните администратори могат да управляват институциите, администраторите на институциите, данните за достъп до API на институциите, както и записите от одита на административните дейности. Тези права не предоставят достъп до ръкописи, рецензии или редакционно съдържание.

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

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

Настоящите области на приложение включват:

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

Упълномощенията на машината не могат да променят ролите в OWNER.

Видимост по време на изпълнение

Активният профил на разгръщане се предоставя от бекенда на Studio и се показва в долната част на приложението като OMI Studio · Personal или OMI Studio · Institutional. Когато ORCID използва мрежата „Sandbox“, в долната част се показва допълнително ORCID Sandbox.

GET /api/auth/providers също така разкрива несекретни метаданни за внедряването и доставчика. Например:

{
  "deployment": {
    "mode": "institutional",
    "label": "Institutional"
  },
  "providers": {
    "orcid": {
      "enabled": true,
      "environment": "sandbox",
      "credentialSource": "institutional",
      "apiType": "public"
    }
  }
}

Ограничения при проектирането

• Режимът на разгръщане се управлява от сървъра, а не от състоянието на браузъра.
• Моделът на документа и пакетите за преносимост „OMI“ остават еднакви и в двата режима.
• Едни и същи бинарни файлове на Studio могат да се използват както за лични, така и за институционални инсталации.
• ORCID Studio никога не обработва паролите.
• Идентичностите в тестовата среда и в производствената среда на ORCID остават разделени по издател.
• Правата на институционалните и централните администратори са отделни от правата за работа с ръкописи и редакционните права.
• Ролите на институциите и централните роли представляват отделни нива на оторизация.
• За първоначалното привилегировано стартиране са необходими както акаунт, включен в списъка с разрешени, така и свързана OIDC/SAML идентичност.
• Удостоверенията за достъп до системата на институцията API са обвързани с обхват и с конкретна институция.
• Личният режим може да пренасочва удостоверяването чрез „OMI Identity“, без да променя интерфейса за влизане в ORCID, който вижда потребителят.

Статус на изпълнението

В настоящата линия на разработка на Studio са внедрени: маршрутизиране на удостоверенията за достъп „ORCID“ според конкретната среда на внедряване, федеративно влизане чрез OIDC, институционални членства, удостоверяване на администраторите на институциите, централизирано администриране, удостоверения за достъп „API“ с ограничен обхват за администраторите на институциите, както и събития за одит на администрирането.

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