Настройка безопасности для приложений на облачной платформе SAP Cloud Platform07.05.2018 16:03

В нашей облачной платформе SAP Cloud Platform есть целый набор встроенных сервисов. В этой статье мы остановимся теме безопасности — рассмотрим сервисы безопасности в среде Neo, а также возможности SAP Cloud Platform для обеспечения безопасности разработанных вами приложений и сервисов.

В этой статье мы расскажем о следующих темах, чтобы лучше понимать возможности сервисов безопасности SAP Cloud Platform, а также — что понимается под теми или иными терминами:

аутентификация пользователей
управление авторизацией
безопасный перенос информации идентификации между разными средами и приложениями («объединение идентификации» или identity federation)
технология единого входа (single sign-on) на SAP Cloud Platform
разница между бизнес-пользователями и пользователями платформы со стороны безопасности

Затем мы рассмотрим практический пример на бесплатном пробном аккаунте SAP Cloud Platform — его может создать любой желающий. В этой части мы расскажем, как работает конфигурация безопасности для приложения в зависимости от его среды выполнения (например, HTML5 и Java).

План нашей статьи о сервисах безопасности SAP Cloud Platform в среде Neo:

Часть 1 (теоретическая). Обзор сервисов безопасности
Часть 2. Настройка безопасности для HTML5-приложений
Часть 3. Настройка безопасности для Java-приложений

(далее — опять очень много текста)

Часть 1. Обзор сервисов безопасности

Одной из ключевых концепций SAP Cloud Platform является то, что аутентификация и управление авторизацией в любом сценарии, запущенном на платформе, осуществляется через так называемого провайдера идентификаций (IdP). Эта система предназначена для безопасного управления пользователями. Пользователи могут быть разных типов — обычные сотрудники, администраторы и другие. Задача безопасного управления этими пользователями, особенно безопасного управления их учетными данными часто делегируется провайдеру идентификаций. Он предоставляет идентификационную информацию приложениям, которые зависят от него, для обеспечения безопасности аутентификации и управления учетными записями пользователей.

Никто не захочет отслеживать тысячи учетных записей пользователей, создавать новых пользователей и новые пароли снова и снова. У большинства из нас имеется огромный список паролей и учетных записей пользователей для различных приложений, с которыми приходится работать ежедневно. Не проще ли централизовать управление пользователями? Это позволит повторно использовать существующие учетные записи. Именно для этого и существует провайдер идентификаций, который надежно хранит учетную запись пользователя и управляет ею. SAP Cloud Platform предлагает интеграцию с любым провайдером идентификаций, который вы как разработчик приложения хотите использовать для управления учетными записями пользователей.
Например, в продуктивном сценарии пользователи являются сотрудниками, которые используют новое приложение на базе платформы SAP Cloud Platform. В этом случае корпоративный каталог пользователя является поставщиком удостоверений.

Для B2C-сценария учетная запись пользователя может быть учетной записью соцсети — Twitter, Facebook, Google и т.д. В этом случае социальные сети берут на себя роль провайдера идентификаций.

SAP Cloud Platform также предлагает поставщика удостоверений от SAP в качестве опции. Поэтому, если вы хотите быстро начать работу и у вас нет провайдера идентификации, который позволяет вам быстро настроить несколько учетных записей для тестирования, то вы всегда можете использовать службу SAP ID в качестве стандартного провайдера идентификации. Она управляет довольно большим количеством учетных записей пользователей для SAP. Например, пользователем службы SAP ID является ваш пользователь пробной учетной записи в SAP Cloud Platform или, если вы являетесь клиентом SAP, ваш S-пользователь. Однако у SAP ID есть некоторые ограничениями с точки зрения разработчика, который хочет развернуть приложение на платформе SAP Cloud Platform и использовать эту службу в качестве провайдера. Вы не сможете контролировать процесс регистрации пользователя в SAP ID и не сможете просто удалить пользователя из этой пользовательской базы, потому что это пользовательская база SAP.

Итак, первый вариант провайдера — это SAP ID:
Общедоступный провайдер идентификаций SAP в Интернете

Бесплатный сервис
Провайдер идентификаций по умолчанию для бизнес-приложений, запущенных в бесплатных пробных учетных записях SAP CP
Провайдер идентификаций по умолчанию для панели управления SAP Cloud Platform и консольного клиента

Если же вы хотите иметь свой собственный тенант с полным контролем, то вы можете воспользоваться облачным провайдером идентификации, который предоставляется как часть службы в SAP Cloud Platform и называется службой аутентификации идентификаций (Identity Authentication). Эта служба похожа на SAP ID, но она предоставляется в качестве вашего собственного тенанта, который вы как клиент можете использовать для полного управления пользовательской базой в этом тенанте. Вы также можете настроить внешний вид, пользовательские интерфейсы, разместить собственный логотип. И самое главное — вы можете контролировать уровень безопасности с точки зрения политики паролей, которую вы устанавливаете для вашего тенанта и для пользователей в нем. Например, если вы используете его для какого-то сценария клиента, то требования могут быть не такими строгими, как для сотрудников, которым необходимо менять свои пароли каждые три месяца (или что-то в этом роде). Таким образом, встроенный сервис SAP Cloud Platform более функционален в сравнении с бесплатным SAP ID. Однако он является платным — на бесплатном триальном аккаунте служба Identity Autentification доступна не будет.

Второй вариант — Identity Authentication:

Облачное решение для управления жизненным циклом идентификации
Рекомендуемый и предварительно настроенный провайдер идентификаций для бизнес-приложения в продуктивных учетных записях SAP Cloud Platform
Настраиваемый провайдер идентификаций для панели управления SCP и консольного клиента
Платный сервис

Что делать, если вам нужна возможность интеграции с существующим корпоративным провайдером идентификаций? В SAP Cloud Platform предусматрена и такая возможность. В данном сценарии поддерживается как провайдер SAP, так и сторонние провайдеры — например, Microsoft Active Directory. Единственное условие для интеграции с выбранным провайдером — он должен быть совместим с языком разметки безопасности SAML 2.0, известным стандартом в этом пространcтве. Этот протокол поддерживается не только SAP, но и почти любым другим провайдером идентификаций.
Таким образом, вы можете очень легко интегрировать платформу и ваши приложения, запущенные на SAP Cloud Platform, с выбранным вами провайдером идентификаций.

Третий вариант — корпоративный провайдер идентификаций:

Настраиваемый провайдер идентификаций для бизнес-приложений SAP CP в любом аккаунте (пробном и продуктивном)
Включает интеграцию с корпоративной идентификацией и доступом управления (IAM)
Необходимое условие: соответствие SAML 2.0

Теперь рассмотрим различные типы пользователей и варианты использования провайдера идентификаций в зависимости от этого.

На самом деле, ограничений почти нет. Существует два типа пользователей: бизнес-пользователи и пользователи платформы. Эту терминологию можно встретить практически в любой теме, касающейся SAP Cloud Platform. Бизнес-пользователи авторизуются в качестве конечного пользователя для приложений, работающих на SAP Cloud Platform. Например, если вы используете SuccessFactors, то у вас есть бизнес-пользователь, управляющий данными сотрудника. Частный пользователь, который входит в систему, например, через вашу учетную запись в Twitter, также может использоваться в качестве бизнес-пользователя. Таким образом, бизнес-пользователь — это и есть конечный пользователь.

Пользователи платформы — это пользователи, которые выполняют административные задачи на платформе. Таких пользователей гораздо меньше в сравнении с бизнес-пользователями. Обычно они являются разработчиками или администраторами вашего приложения и, как правило, работают с такими инструментами, как панель управления (Cloud Cockpit), консольный клиент или же инструменты Eclipse для взаимодействия с платформой.

На рисунке ниже представлены варианты использования провайдеров идентификаций в зависимости от типа пользователя, а также указаны некоторые рекомендации.

Бизнес-пользователь может использовать службу SAP ID в качестве провайдера. Но всё же для продуктивных сценариев рекомендуется использовать службу SAP Cloud Platform Identity Authentication или корпоративного провайдера, чтобы иметь полный контроль, а SAP ID использовать для тестирования.

Пользователь платформы может так же использовать все три вида провайдеров идентификаций: SAP ID, SAP Cloud Platform Identity Authentication и ваш корпоративный IDP. Но у такого пользователя есть некоторые ограничения по использованию корпоративного IDP: при этом сценарии не получится воспользоваться клиентом консоли для среды Neo для аутентификации пользователей платформы. В итоге вы получаете довольно богатый набор опций.

Теперь поговорим немного об авторизации в SAP Cloud Platform. Если вы являетесь пользователем платформы, то вам присваиваются роли на уровне платформы. В среде Neo это могут быть предопределенные роли — для администраторов, разработчиков или пользователей поддержки. В среде Neo SAP Cloud Platform предоставляется набор предопределенных ролей, и если вы, например, пользуетесь продуктивным аккаунтом и являетесь в нем администратором, то сможете назначить участникам вашего аккаунта любую из этих ролей. Кстати, пользователи платформы — это и есть члены учетной записи. В панели управления есть вкладка в меню, которая называется «Members» (или «Участники») — именно здесь вы можете добавлять пользователей платформы и назначать им роли.

Для бизнес-пользователей этот процесс устроен немного иначе. У вас должна быть возможность назначать роли тысячам или даже десяткам тысяч бизнес-пользователей. Здесь речь идет уже не о ролях на уровне платформы, а о ролях, определенных вашими бизнес-приложениями. Чтобы присвоить роль бизнес-пользователю, вы можете зайти в панель управления SAP Cloud Platform через вашего пользователя платформы и «статически» добавить бизнес-пользователей в те роли, которые определены бизнес-приложениями.

Но представьте, что в какой-то момент времени эта модель уже не масштабируется, особенно если вам нужно назначить огромное количество бизнес-ролей столь же огромному количеству бизнес-пользователей. Для этой задачи в среде Neo можно использовать «группы». В основном эти группы охватывают одну или несколько ролей приложений в одном объекте на платформе, и после добавления бизнес-пользователя в такую группу происходит автоматическое назначение пользователя всем этим бизнес-ролям из приложений, которые присвоены этой группе. Вы можете использовать некоторые свойства, которые пользователи могут здесь установить. Например, если пользователи принадлежат к отделу, который работает главным образом в Москве, то они должны видеть данные только из Москвы.

Таким образом, назначение ролей бизнес-пользователю через настройки вашего приложения в панели управления SAP Cloud Platform может быть сделано только статически — это означает, что вы назначаете пользователя с идентификатором «abc» на роль «xyz», и до тех пор, пока вы это не измените (например, удалите идентификатор пользователя), роль будет присвоена.
Присвоение бизнес-пользователя группе также может выполняться статически — т.е вы назначаете этого пользователя «abc» группе, и тогда вам не придется назначать каждую роль отдельно. Это можно сделать и динамически, т.е. на основе атрибута, который разделяют тысячи или миллионы бизнес-пользователей. Данный атрибут может использоваться в среде выполнения в тот момент, когда пользователь авторизуется в приложении на SAP Cloud Platform, чтобы назначить пользователя группе динамически на основе этого атрибута и его значения.

Для администратора (пользователя платформы) это означает, что не нужно каждый раз выполнять действия по присвоения ролей.

Как только атрибут изменяется, а значение этих атрибутов объединения обычно изменяется в базовой пользовательской базе, то при входе пользователя в систему в следующий раз присвоение роли или происходит, или нет, в зависимости от значения этого атрибута.

Часть 2. Настройка безопасности для HTML5 приложений

Многие пользователи SAP Cloud Platform как правило используют HTML5 и Java для построения своих приложений в среде Neo. Реализация пользовательского интерфейса бизнес-приложения с современной технологией на основе библиотек Fiori и SAPUI5 происходит в части приложения HTML5. Более сложная бизнес-логика может находиться в бэкенд-системе — например, в корпоративной сети или определенной системе SAP, обычно она реализована на Java. Оба приложения, HTML5 или Java имеют смысл, если взаимодействуют друг с другом. Каждое из них реализует разные, но взаимодополняющие функции.

В этой части мы рассмотрим HTML5-приложение. xProject — это простое приложение для управления проектами. Например, сотрудники могут использовать приложение на SAP Cloud Platform, чтобы управлять проектами и отслеживать время, потраченное на различные задачи на предприятии.

Если вы входите в рабочую группу определенного проекта, то это приложение должно позволить вам залогиниться и записать потраченное рабочее время на различные проекты на предприятии. Также существует группа пользователей, которые являются администраторами в этом приложении.

Таким образом, у нас есть бизнес-пользователи, которые делятся на две группы. Также есть HTML5-приложение, которое используется в качестве интерфейса, и Java-приложение — для бэкенда. В нашем случае Java-часть приложения предлагает RESTful API, использующий HTTP-протокол для предоставления этой бизнес-функции компоненту, который хочет ее использовать. Веб-приложения предлагают API для интерфейса пользователя, а также для других клиентов, которые могут использовать бизнес-функциональность, предлагаемую Java-частью приложения.

Рассмотрим в деталях HTML5-приложение и аутентификацию бизнес-пользователей. Как мы уже выяснили, у нас есть выбор поставщиков идентификаций. Концепция SAP Cloud Platform заключается в делегировании аутентификации поставщику идентификаций. Для данного сценария мы будем использовать SAP ID в качестве поставщика идентификаций, поэтому приложение HTML5 делегирует аутентификацию SAP ID. Мы рассмотрим аутентификацию конечных пользователей, их авторизацию на стороне HTML5, а также процесс получения определенной информации о пользователе путем использования информации о пользователе из службы SAP ID в приложении HTML5. Благодаря этому появляется возможность чтения атрибутов пользователя — например, имя пользователя. Но служба SAP ID использует ограниченный набор атрибутов: имя, фамилию, адрес электронной почты и отображаемое имя. Эти атрибуты мы можем использовать на стороне HTML5 для отображения пользователю.

Для тестирования нам понадобится HTML5 демо-приложение под названием xProject, которое можно найти в репозитории GitHub:.
Используйте инструкцию в README.md в этом репозитории, чтобы загрузить приложение в SAP Cloud Platform.

Для создания триального аккаунта в SAP Cloud Platform перейдите по ссылке. Затем выбираем «Neo Trial» в качестве среды на домашней странице (если используется пробный аккаунт) и переходим на вкладку «Applications» → «HTML5 Applications». Далее нужно осуществить шаги, описанные в GitHub.

В результате вы получите запущенное HTML5 приложение.

В Web IDE можно ознакомиться с кодом и функциями, отвечающими за безопасность приложения.

Перейдём в Web IDE и откроем файл «neo-app.json». Этот файл является дескриптором развертывания для приложений HTML5. Именно сюда добавляются свойства для реализации авторизации, чтобы не каждому пользователю было разрешено обращаться к приложениям, а только тем, кто являются членами проекта или руководителями проектов в приложении xProject.

Рассмотрим фрагмент кода файла «neo-app.json»:

} "authenticationMethod": "none", ... "routes": [… ], "securityConstraints": [ { "permission": "accessProjectData", "description": "Access Project Data", "protectedPaths": [ "/protected/" ] } ], ... }

На первом этапе необходимо обозначить методы аутентификации. Если вы хотите обеспечить безопасность HTML5-приложения таким образом, чтобы каждый отдельный его источник был защищен, то вы должны использовать «SAML» в качестве метода аутентификации, который является первым свойством в этом фрагменте.

Но, как видно, в нашем случае используется «none». Это означает, что у нас также есть общедоступные источники в сценарии. Таким образом, если у вас есть источники, которые должны быть доступны для всех (например, это может быть начальная страница приложения), указывается именно этот параметр. В том случае, если вы используете «none» в качестве метода проверки подлинности, то вам также нужно указать в файле дескриптора развертывания, что именно должно быть защищено и доступно только пользователям, принадлежащими к определенной роли. В нашем случае приложение определяет путь, который предшествует «protected» (поэтому и прописывается »/protected/»), и все, что находится под ним, должно быть доступно только пользователям, которые имеют определенную роль.

В дескрипторе развертывания HTML5 вы указываете этот защищенный доступ, объявляя разрешение под названием «Access Project Data». Позже в панели управления (cockpit), мы назначим роль этому разрешению, которую затем можно будет назначить пользователям через этот путь. Но в то же время это означает, что пользователи, которые не имеют данного разрешения, также получают доступ к приложению –, но только к общедоступным его частям.
Теперь рассмотрим другой фрагмент кода, который также представлен в файле «neo-app.json»:

} ... "logoutPage": "/logout.html", ... "cacheControl": [ { "directive": "private", "maxAge": 0, "path": "/protected/*html" }, ... }

После входа в приложение вы также можете выйти из системы, и это свойство в дескрипторе развертывания называется «logoutPage».

Оно определяет, какой должна быть страница для перенаправления пользователя после нажатия на кнопку выхода из приложения. Чтобы ваш браузер после выхода не отображал кешированную страницу, нужно определить для этих страниц в приложении HTML5 максимальный период »0». Это означает, что они не будут кэшироваться. В противном случае вы можете столкнуться с тем, что после нажатия на «Logout» пользователь фактически не выйдет из системы, потому что браузер на самом деле будет показывать вам кешированную страницу. Или же пользователь выйдет из системы, но на странице информация будет отображаться таким образом, будто пользователь все еще находится в ней. Чуть позже мы рассмотрим, как вы можете проверить, выполняется ли этот запрос на выход, и как этот запрос на выход можно проследить в браузере.

Перейдём к следующему фрагменту кода, представленном в файле «neo-app.json»:

... "routes": [ { "path": "/services/userapi", "target": { "type": "service", "name": "userapi" } }, ...

После успешного входа в систему пользователь должен увидеть некоторые данные. Как уже было сказано, при использовании службы SAP ID у нас есть только очень ограниченный набор доступных сведений о пользователе: имя, фамилия и адрес электронной почты. Чтобы увидеть их, нужно указать доступ к API для приложений HTML5, который дает информацию о пользователе, прописав путь »/services /userapi» в файле «neo-app.json».

После этого вы сможете использовать модель JSON, которая обращается к указанному пути для доступа к информации о текущем пользователе. JSON-модель использует данные из службы SAP ID или любого другого поставщика удостоверений и отображает информацию о пользователе в вашем приложении HTML5.

Вернемся в панель управления SAP Cloud Platform, где мы можем обратиться к загруженному из GitHub HTML5 приложению и присвоить пользователям роли.

Перейдём в панель управления среды Neo. Выбираем «HTML5 Applications» во вкладке «Applications», затем нажимаем на приложение с названием «xproject». Перед вами откроется окно с подробной информацией о приложении:

Во вкладке «Overview» найдите описание разрешений на доступ к приложению «Application Permissions». Как видите, здесь находится описанное в файле «neo-app.json» разрешение с названием «accessProjectData».

Сейчас разрешение «accessProjectData» назначено по умолчанию всем пользователям, у которых есть роль разработчика аккаунта. Это пользователи, у которых в разделе членов вашей учетной записи «Members» на уровне платформы есть такая роль (в пробном аккаунте такой вкладки нет, т.к. в нем может быть всего один участник и ему уже присвоены все возможные роли).

Конечно, можно ничего не менять — в таком случае у вас как у разработчика аккаунта будет доступ к приложению и системе. Но мы сделаем несколько по-другому и добавим свою бизнес-роль. Затем в неё назначим пользователей, которым мы хотим предоставить доступ.

Для этого переходим во вкладку «Roles». Как видите, изначально список ролей пуст. Нажимаем на «New Role» для создания новой бизнес-роли.

В открывшемся окне вводим название роли: «Employee» и сохраняем изменения.

Теперь нужно назначить эту роль бизнес-пользователю. Для этого нажмите «Assign»:

После этого появится окно, куда нужно будет ввести ID пользователя.

Введем в появившемся поле ID пользователя другого пробного аккаунта. После назначения этой бизнес-роли в разрешения пользователь другого аккаунта в среде Neo будет иметь доступ к данному приложению. И так как информация об этом пользователе хранится в SAP ID, именно его мы будем использовать в нашем сценарии в качестве провайдера идентификаций. Мы схожем использовать его идентификационные параметры для входа в систему.

Если у вас нет второй пробной учетной записи, вы можете создать ее и ввести в этом поле идентификатор пользователя этого аккаунта.
Например, id пользователя моей второй учетной записи — p1943269512. Я ввожу эти данные в поле «User ID». Обратите внимание, что имя пользователя нужно вводить без trial на конце.

После чего нужно нажать «Assign».

Так будет выглядеть страница после назначения пользователя в роль «Employee». Как видите, пользователь, которому будет разрешен доступ к приложению, отличается от пользователя, под которым мы находимся в панели управления в SCP, где разворачивается приложение.

Теперь нам нужно вернуться назад во вкладку «Overview» и назначить бизнес-роль «Employee» разрешению «accessProjectData». Для этого находим в вкладке «Application Permissions» и нажимаем на «Edit» для редактирования.

Напротив разрешения «accessProjectData» выбираем «Employee» вместо «AccountDeveloper» в качестве роли и нажимаем «Save».

Попробуем запустить приложение. Для этого просто кликните по ссылке на приложение во вкладке «Overview».

Учтите, что окно приложения нужно открывать в режиме инкогнито, иначе при попытке входа могут использоваться данные учетной записи аккаунта, где вы развернули приложение, а не те, что вы указываете. В этом случае вы получите ошибку «HTTP Status 403 — Forbidden».

Перед вами появится начальная страница приложения, которая доступна всем пользователям. Чтобы получить доступ к остальным ресурсам, которые находятся под защищенным путем, нужно пройти аутентификацию. Когда вы нажмете кнопку «Login», это действие принудительно запустит среду выполнения HTML5, чтобы перенаправить пользователя к провайдеру идентификации (в нашем случае это SAP ID).

Нажимаем на кнопку «Login», чтобы авторизоваться:

В появившемся окне вводим имя и пароль пользователя, которого мы добавили в роль «Employee», а затем нажимаем «Вход».

После успешного входа в систему мы получаем сообщение об ошибке доступа к бэкенду, а также красные надписи «Role not assigned». Это происходит, потому что пока что HTML5 не взаимодействует с приложением Java, выступающим в роли бэкенда.

Таким образом, мы вошли в систему как пользователь на сайт HTML5, прошли аутентификацию и получили разрешение на доступ к этой странице. Очевидно, что информация о пользователе, которая использовалась для входа, теперь разделяется между службой SAP ID и приложением HTML5, используя API-интерфейс пользователя. Информация о пользователе, которую вы видите в приветственном окне, как раз поступает из SAP ID сервиса.

Теперь рассмотрим, как происходит выход из системы, используя трассировку SAML. Её можно открыть в разделе «Инструменты разработчика» браузере Google Chrome или установить и открыть в Mozilla Firefox. Нажимаем кнопку «Выход» в виде значка в правой верхней части экрана.

Проверяем, был отправлен ли запрос на выход в окне трассировки SAML.

Как видно из SAML-протокола, что запрос был отправлен, а значит можно быть уверенным, что вы вышли из систем. Если теперь нажать «Login», то нужно будет снова проходить аутентификацию.

Часть 3. Настройка безопасности для Java приложений

Java-приложение содержит бизнес-логику, заботится о сохранности наших данных и позволяет пользователям управлять своими проектами и сообщать время, которое они потратили на эти проекты.

В настройке HTML5-приложения мы рассмотрели аутентификацию конечных пользователей и использовали службу SAP ID для этого. В результате у нас есть аутентифицированный пользователь, который теперь должен быть передан на Java часть нашего приложения xProject. И теперь нам нужно понять, как аутентифицируется конечный пользователь в приложении Java? Как аутентифицированный пользователь, или по-другому «principal», получает доступ из пользовательского интерфейса (из приложения HTML5) к приложению Java? Когда пользовательский интерфейс использует API-интерфейсы, относящиеся к Java-приложению, чтобы использовать бизнес-логику Java? И главный вопрос: как реализовать этот механизм получения доступа к Java через HTML5? Это метод еще называют «Principal Propagation».

Так как пользователь получает доступ к данным проекта в этом сценарии — нам необходимо применить модель авторизации на основе ролей в бэкенде Java-приложения и реализовать возможность устанавливать пользователю разрешение на просмотр данных.

В HTML5-приложении наша модель авторизации была довольно жесткой. Мы определили одно разрешение, «accessProjectData», которому была назначена бизнес-роль «Employee», и в эту роль добавили бизнес-пользователя. Таким образом, у этого пользователя появляется доступ к части пользовательского интерфейса приложения после успешного входа в систему с помощью службы SAP ID.

Теперь мы хотим получить доступ к своим данным, которые управляются и хранятся на стороне Java-приложения нашего приложения. Нам нужно организовать более детальную концепцию авторизации с помощью двух ролей.

Рассмотрим модель авторизации сценария. Когда дело доходит до доступа к данным в бэкенде, мы должны применять более детальную модель авторизации, по сравнению с моделью на стороне HTML5. Для нашего сценария мы используем две разные роли, которые определены в Java. Одна из них предназначена для членов проекта, а другая — для менеджеров проектов. Участники проекта могут обозначать свое время в проектах, которые им назначены, а менеджеры проекта в приложении могут также создавать новые проекты и выполнять административную часть в бизнес-приложении. Менеджеры проектов могут назначать участников проектов, удалять их и так далее. Таким образом, все административные элементы будут доступны только для пользователей, которым назначена роль менеджера проекта, а остальные элементы — для участников проекта.

Нам понадобится Java демо-приложение под названием xProject, которое можно найти в репозитории GitHub.

Следуя шагам в README.md в этом репозитории, загрузите это приложения в SAP Cloud Platform через среду разработки Eclipse NEON. Учтите, что вам понадобится установить «SAP Cloud Platform Tools for Java» в Eclipse. Для этого перейдите в меню Help → Install new Software… в открывшемся окне введите URL tools.hana.ondemand.com/neon и установите необходимые компоненты.

Для настройки безопасности Java-приложения в дескрипторе развертывания обычно указываются требования проверки подлинности. Подобно файлу «neo-app.json» для приложения HTML5 у нас также есть соответствующий дескриптор развертывания для приложений на основе Java — он называется «web.xml».

Обратимся к исходному коду этого приложения в Eclipse, чтобы рассмотреть методы авторизации и аутентификации, описанные в вышеупомянутом файле «web.xml».

Наиболее важной его частью является свойство «login-config», описывающее метод проверки подлинности, т.е. какой механизм аутентификации должен использоваться для аутентификации ваших бизнес-пользователей:

…

FORM

…

В нашем сценарии, как видно из фрагмента, используется метод FORM. FORM позволяет использовать аутентификацию на основе SAML, т.к. мы всегда делегируем аутентификацию поставщику удостоверений по вашему выбору, совместимому с SAML 2.0. Метод FORM также описывает «application-to-application SSO» или «единый вход в приложение», что обеспечивает взаимодействие между приложениями. Поэтому в «web.xml» всегда должна указываться конфигурация входа.
Для обращения к компоненту HTML5, который вызывает API-интерфейсы Java-бэкенда, нужен следующий фрагмент в этом же файле:
"routes": [ ... { "path": "/api/projects", "target": { "type": "destination", "name": "projectAPI" }, "description": "Project API" }, ... ], ...

Вызов этих API-интерфейсов происходит через так называемые «пункты назначения» или «destinations». Вы настраиваете пункт назначения всякий раз, когда совершаете вызов компонента, который находится на платформе SAP Cloud Platform или за ее пределами. То есть требуется указать название пункта назначения в компоненте вызова приложения. В нашем случае это будет часть HTML5.

В дескрипторе развертывания «neo-app.json» путь к API для извлечения данных проекта из бэкенда настраивается как пункт назначения, который ссылается на пункт назначения с именем «projectAPI». Потом мы будем использовать это имя в панели управления SAP Cloud Platform, когда будем создавать пункт назначения. Фактически нам нужны будут два пункта назначения: один для извлечения данных проекта, а другой — для получения данных для расписания, которое люди будут смотреть через приложение. Эти два пункта необходимы приложению HTML5 для успешного вызова бэкенда на Java. Они будут созданы в панели управления SCP, чтобы приложение HTML5 могло понять, какие URL-адреса будут обращаться к приложению Java. Именно поэтому мы должны указать фактический URL-адрес и техническую конечную точку URL-интерфейса API, предоставляемые Java-приложением.

Когда вы успешно авторизовались в приложение HTML5, вы увидите сообщение об ошибке доступа к бэкенду. Это происходит из-за того, что эти пункты назначения отсутствуют — ошибку нужно исправить.

Обратимся к следующему фрагменту кода в файле «web.xml»:

... ProjectManager ProjectMember ... Protected APIs /api/v1/* ProjectManager ProjectMember ...

Как мы уже выяснили, у нас есть две роли для Java-приложения: менеджер проекта и участник проекта. Мы должны осведомить нашу среду об этих двух ролях. Для этого они должны быть указаны разработчиком в файле «web.xml» приложения Java в качестве ролей безопасности.

Когда приложение будет загружено в SCP, нам нужно назначить эти роли защищенным путям приложения. Каждый раз, когда будет вызван этот защищенный путь, который в нашем случае является API-интерфейсом приложения Java для управления проектами, аутентифицированный пользователь должен принадлежать одной из этих двух ролей, чтобы успешно использовать бэкенд. Таким образом, мы можем описать в дескрипторе установки нужные нам роли, а затем — только назначить нужных пользователей этим ролям.

Итак, наше приложение было загружено в SCP согласно инструкции в репозитории GitHub. Теперь давайте перейдём в панель управления SCP.

Заходим в н