Некоторое время назад передо мной встала задача, в целях защиты коммерческой тайны своих клиентов, отказаться от использования сторонних облачных сервисов.
Первое и самое логичное – предоставить им доступ на уже имеющийся в наличии Synology.
И тут возникло желание сделать это красиво, не отдельным логином/паролем, а с использованием уже выданных ранее от личного кабинета. «Бесшовный» переход из личного кабинета на сервисы Synology – то, что нужно.
Описание и скрипт под катом.
Для дальнейшей работы нам понадобятся установленный LDAP Server и SSO Server.
SSO Server – это собственная реализация OAuth2.0 от Synology.
Настраиваем LDAP и заводим нужного пользователя, устанавливаем ему права на доступы к сервисам.
Далее вступает в работу написанный мной php скрипт, который мы устанавливает на сайт. Он не большой и выложен на GitHub.
С ним все просто. Скачиваем и размещаем на сайт в папку /my.
В config.php нужно заменить следующие значения на свои:
В index.php (место обозначено) добавить дальнейшую логику или переадресацию после того как пользователь успешно авторизован.
Ну и сам скрипт обработки запросов:
Далее необходимо привязать авторизацию на сайте через SSO Server. В нем все совсем просто – Открываем SSO Server > Список приложений > Добавить > Вводим название и URI адрес на скрипт SSO_Oauth.php. После нажатия на «Ок», будет сгенерирован ID приложения. Его нужно скопировать и разместить в нашем config.php > APP_ID.
Таким образом, если пользователь прошел авторизацию на вашем сайте через SSO, то перейдя по ссылке на любой из сервисов Synology, к которому у него открыт доступ в LDAP, ему не прийдется проходить повторную авторизацию. Это актуально и в обратную сторону – если он авторизовался в вашем облаке, то личный кабинет на сайте также будет доступен.
Реализация оказалась не такой и простой. В сети я нашел только один guide по данного API – Synology SSO API Guide, но там все делается на стороне клиента через ajax и по какой-то причине не определялось, что пользователь авторизован, а также работало ооочень медленно. Поэтому пришлось находить свое решение, но оно оказалось гораздо короче и проще.
Буду рад, если еще кому-то пригодится.
Первое и самое логичное – предоставить им доступ на уже имеющийся в наличии Synology.
И тут возникло желание сделать это красиво, не отдельным логином/паролем, а с использованием уже выданных ранее от личного кабинета. «Бесшовный» переход из личного кабинета на сервисы Synology – то, что нужно.
Описание и скрипт под катом.
Для дальнейшей работы нам понадобятся установленный LDAP Server и SSO Server.
SSO Server – это собственная реализация OAuth2.0 от Synology.
Настраиваем LDAP и заводим нужного пользователя, устанавливаем ему права на доступы к сервисам.
Далее вступает в работу написанный мной php скрипт, который мы устанавливает на сайт. Он не большой и выложен на GitHub.
С ним все просто. Скачиваем и размещаем на сайт в папку /my.
В config.php нужно заменить следующие значения на свои:
config.php
<?php
define('APP_ID', 'a8d0f0835eda3517f3e8fd70c10500e7');
define('SSO_HOST', 'https://DSM:5001');
define('LOCAL_HOST', 'https://yourwebsite.ru');
define('REDIRECT_URI', 'https://yourwebsite.ru/my/SSO_Oauth.php');
?>
- APP_ID – вы получите его на следующем этапе, при регистрации в SSO Server
- SSO_HOST – адрес хоста для доступа к Synology
- LOCAL_HOST – адрес сайта на котором лежит скрипт
- REDIRECT_URI – адрес по которому доступен скрипт SSO_Oauth.php
В index.php (место обозначено) добавить дальнейшую логику или переадресацию после того как пользователь успешно авторизован.
index.php
<?php
session_start();
include_once('config.php');
if (!isset($_SESSION['user_id'])) {
header('location: '.SSO_HOST.'/webman/sso/SSOOauth.cgi?app_id='.APP_ID.'&scope=user_id&redirect_uri='.REDIRECT_URI);
}
if (isset($_GET['logout'])) {
unset($_SESSION['user_id']);
header('location: '.LOCAL_HOST);
}
// here we can do something after login
echo 'User ID:'.$_SESSION['user_id'].' logged in';
?>
Ну и сам скрипт обработки запросов:
SSO_Oauth.php
<?php
session_start();
include_once('config.php');
if (isset($_GET['access_token'])) {
$access_token = $_GET['access_token'];
$resp = file_get_contents(SSO_HOST.'/webman/sso/SSOAccessToken.cgi?action=exchange&access_token='.$access_token.'&app_id='.APP_ID);
$json_resp = json_decode($resp, true);
if($json_resp['success'] == true){
$_SESSION['user_id'] = $json_resp["data"]["user_id"];
header('location: '.LOCAL_HOST.'/my/');
}
exit();
}
?>
<html>
<body>
<script>
var get = window.location.hash.substr(1);
if (get) {
window.location.href = "<?=REDIRECT_URI?>?" + get;
}
</script>
</body>
</html>
Далее необходимо привязать авторизацию на сайте через SSO Server. В нем все совсем просто – Открываем SSO Server > Список приложений > Добавить > Вводим название и URI адрес на скрипт SSO_Oauth.php. После нажатия на «Ок», будет сгенерирован ID приложения. Его нужно скопировать и разместить в нашем config.php > APP_ID.
Таким образом, если пользователь прошел авторизацию на вашем сайте через SSO, то перейдя по ссылке на любой из сервисов Synology, к которому у него открыт доступ в LDAP, ему не прийдется проходить повторную авторизацию. Это актуально и в обратную сторону – если он авторизовался в вашем облаке, то личный кабинет на сайте также будет доступен.
Реализация оказалась не такой и простой. В сети я нашел только один guide по данного API – Synology SSO API Guide, но там все делается на стороне клиента через ajax и по какой-то причине не определялось, что пользователь авторизован, а также работало ооочень медленно. Поэтому пришлось находить свое решение, но оно оказалось гораздо короче и проще.
Буду рад, если еще кому-то пригодится.
mepihin
Лучше всего было выложить код сюда и объяснить его. Вы заставляете людей переходить на другой сайт, чтобы понять о чем речь. Оставьте просто ссылку на исходник, а код покажите в статье и объясните. Было бы хорошо иметь наглядную схему потоков данных и процессов.
dagababaev Автор
Без проблем
vasyakrg
Тут из текста уже все понятно и без схем с потоками (?) данных.
Как собственно и с кодом: проверка токена, подстановка хедеров с переменных конфига и редирект. Просто и со вкусом.
dagababaev Автор
У меня и стояла задача сделать просто, но минус уже влепить кто-то успел как раз за простоту :)
Данный пост касается реализации именно SSO. У него есть свой прикол и не все так интуитивно, особенно если изначально идти от официальной документации