Как сделать сквозную авторизацию

Обновлено: 09.01.2025

Здравствуйте! Появилась необходимость в настройке сквозной авторизации доступа к почтовому ящику через OWA для пользователей, которые находятся в домене.
Необходима помощь как правильно это сделать. Нашёл некоторую информацию, что необходимо для этого на сервере Exchange в свойствах OWA поставить галочку "Встроенная проверка подлинности Windows". Так ли это?

Lexuz

Случайный прохожий

Появилась необходимость в настройке сквозной авторизации доступа к почтовому ящику через OWA для пользователей, которые находятся в домене.

ConfigExchangeURL

ConfigureExchangeURLs.ps1 - это сценарий PowerShell, позволяющий быстро и легко настроить пространства имен клиентского доступа на серверах Exchange. Сценарий предназначен для применения одного и того же пространства имен ко всем службам.

Как я понимаю нужно этот параметр выставить

IISAuthenticationMethods
ExternalClientAuthenticationMethod : Negotiate
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods :

Engineer

Участник

Lehhaa

Участник

Помоему не может быть разных методов аутентификации в одном виртуальном каталоге. Можно попробовать создать еще один виртуальный каталог OWA, отдельно для внешних / внутренних пользователей и соответствующим образом настроив аутентификацию.
Обратите внимание, что для этого требуется 2 IP-адреса для пространства имен OWA и 2 веб-сайта и виртуальных каталогов.

Hyper

Участник

Зачем тогда эти 2 параметра
IISAuthenticationMethods
ExternalClientAuthenticationMethod : Negotiate
InternalClientAuthenticationMethod : Ntlm

Все знают о стандартной аутентификации пользователя в приложении. Это олдскульная процедура регистрации — пользователь вводит адрес почты, пароль и т. д., — а затем при входе мы сравниваем почту и/или пароль с сохранёнными данными. Если совпадает, даём доступ. Но времена изменились, и сегодня появилось много других методов аутентификации. Если хотите оставаться востребованным программистом/разработчиком в этом меняющемся, словно калейдоскоп, мире разработки ПО, то вы должны знать обо всех этих новых методах.

Здесь я постараюсь рассказать о большинстве распространённых сегодня методов аутентификации. Это не подробное техническое руководство, а лишь способ познакомить вас с ними. Хотя методы описаны с учётом применения в вебе, эти идеи можно реализовать и в других условиях.

Аутентификация на основе сессий

Чтобы избавиться от этого неудобства, придумали аутентификацию на основе сессий/кук, с помощью которых реализовали отслеживание состояний (stateful). Это означает, что аутентификационная запись или сессия должны храниться и на сервере, и на клиенте. Сервер должен отслеживать активные сессии в базе данных или памяти, а на фронтенде создаётся кука, в которой хранится идентификатор сессии. Это аутентификация на основе куки, самая распространённый и широко известный метод, используемый уже давно.

Процедура аутентификации на основе сессий:

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

У этого метода несколько недостатков.

При каждой аутентификации пользователя сервер должен создавать у себя запись. Обычно она хранится в памяти, и при большом количестве пользователей есть вероятность слишком высокой нагрузки на сервер.
Поскольку сессии хранятся в памяти, масштабировать не так просто. Если вы многократно реплицируете сервер, то на все новые серверы придётся реплицировать и все пользовательские сессии. Это усложняет масштабирование. (Я считал, этого можно избежать, если иметь выделенный сервер для управления сессиями, но это сложно реализовать, да и не всегда возможно.)

Аутентификация на основе токенов

Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT) . Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.

При аутентификации на основе токенов состояния не отслеживаются . Мы не будем хранить информацию о пользователе на сервере или в сессии и даже не будем хранить JWT, использованные для клиентов.

Процедура аутентификации на основе токенов:

Пользователь вводит имя и пароль.
Сервер проверяет их и возвращает токен (JWT), который может содержать метаданные вроде user_id, разрешений и т. д.
Токен хранится на клиентской стороне, чаще всего в локальном хранилище, но может лежать и в хранилище сессий или кук.
Последующие запросы к серверу обычно содержат этот токен в качестве дополнительного заголовка авторизации в виде Bearer . Ещё токен может пересылаться в теле POST-запроса и даже как параметр запроса.
Сервер расшифровывает JWT, если токен верный, сервер обрабатывает запрос.
Когда пользователь выходит из системы, токен на клиентской стороне уничтожается, с сервером взаимодействовать не нужно.

У метода есть ряд преимуществ:

Главное преимущество: поскольку метод никак не оперирует состояниями, серверу не нужно хранить записи с пользовательскими токенами или сессиями. Каждый токен самодостаточен, содержит все необходимые для проверки данные, а также передаёт затребованную пользовательскую информацию. Поэтому токены не усложняют масштабирование.
В куках вы просто храните ID пользовательских сессий, а JWT позволяет хранить метаданные любого типа, если это корректный JSON.
При использовании кук бэкенд должен выполнять поиск по традиционной SQL-базе или NoSQL-альтернативе, и обмен данными наверняка длится дольше, чем расшифровка токена. Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных.
Допустим, у вас есть API-ресурс /api/orders, который возвращает последние созданные приложением заказы, но просматривать их могут только пользователи категории админов. Если вы используете куки, то, сделав запрос, вы генерируете одно обращение к базе данных для проверки сессии, ещё одно обращение — для получения пользовательских данных и проверки, относится ли пользователь к админам, и третье обращение — для получения данных.
А если вы применяете JWT, то можете хранить пользовательскую категорию уже в токене. Когда сервер запросит его и расшифрует, вы можете сделать одно обращение к базе данных, чтобы получить нужные заказы.
У использования кук на мобильных платформах есть много ограничений и особенностей. А токены сильно проще реализовать на iOS и Android. К тому же токены проще реализовать для приложений и сервисов интернета вещей, в которых не предусмотрено хранение кук.

Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.

Беспарольная аутентификация

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

Беспарольная аутентификация — это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая:

Вместо ввода почты/имени и пароля пользователи вводят только свою почту. Ваше приложение отправляет на этот адрес одноразовую ссылку, пользователь по ней кликает и автоматически входит на ваш сайт / в приложение. При беспарольной аутентификации приложение считает, что в ваш ящик пришло письмо со ссылкой, если вы написали свой, а не чужой адрес.

Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Но тогда придётся объединить ваше приложение с SMS-сервисом вроде twilio (и сервис не бесплатен). Код или одноразовый пароль тоже можно отправлять по почте.

И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев. Подробнее о технологии .

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

Medium предоставляет доступ к своему сайту только по почте . Я недавно обнаружил, что Auth0 , или Facebook AccountKit , — это отличный вариант для реализации беспарольной системы для вашего приложения.

Что может пойти не так?

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

В чём преимущества?

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

Если вы думаете, что какие-то пользователи предпочтут старомодные логин/пароль, то предоставьте им оба варианта, чтобы они могли выбирать.

Сегодня беспарольная аутентификация быстро набирает популярность.

Единая точка входа (Single Sign On, SSO)

Обращали внимание, что, когда логинишься в браузере в каком-нибудь Google-сервисе, например Gmail, а потом идёшь на Youtube или иной Google-сервис, там не приходится логиниться? Ты автомагически получаешь доступ ко всем сервисам компании. Впечатляет, верно? Ведь хотя Gmail и Youtube — это сервисы Google, но всё же раздельные продукты. Как они аутентифицируют пользователя во всех продуктах после единственного входа?

Этот метод называется единой точкой входа (Single Sign On, SSO).

Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts . Когда пользователь логинится, Google Accounts создаёт куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:

Пользователь входит в один из сервисов Google.
Пользователь получает сгенерированную в Google Accounts куку.
Пользователь идёт в другой продукт Google.
Пользователь снова перенаправляется в Google Accounts.
Google Accounts видит, что пользователю уже присвоена кука, и перенаправляет пользователя в запрошенный продукт.

Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю.

Выглядит очень просто, но конкретные реализации бывают очень сложными. Подробнее об этом методе аутентификации .

Аутентификация в соцсетях

Уверен, эта картинка знакома всем:

Это часто называют аутентификацией в соцсетях (Social sign-in) или социальным логином (Social Login). Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придётся регистрироваться отдельно в вашем приложении.

Формально социальный логин — это не отдельный метод аутентификации. Это разновидность единой точки входа с упрощением процесса регистрации/входа пользователя в ваше приложение.

Лучшее из двух миров

Пользователи могут войти в ваше приложение одним кликом, если у них есть аккаунт в одной из соцсетей. Им не нужно помнить логины и пароли. Это сильно улучшает опыт использования вашего приложения. Вам как разработчику не нужно волноваться о безопасности пользовательских данных и думать о проверке адресов почты — они уже проверены соцсетями. Кроме того, в соцсетях уже есть механизмы восстановления пароля.

Как использовать

Как разработчик вы должны разбираться в работе этого метода аутентификации. Большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth2 (некоторые используют OAuth1, например Twitter). Разберёмся, что такое OAuth. Соцсеть — это сервер ресурсов , ваше приложение — клиент , а пытающийся войти в ваше приложение пользователь — владелец ресурса . Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмёт этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).

Для реализации такого механизма вам может понадобиться зарегистрировать своё приложение в разных соцсетях. Вам дадут app_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport , Laravel Socialite и т. д.), которые помогут упростить процедуру и избавят от излишней возни.

Двухфакторная аутентификация (2FA)

Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации . Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.

От автора: рано или поздно каждый веб-разработчик сталкивается с задачей по ограничению доступа к некоей странице/страницам или каталогу. Это может быть просто секретная страница на сайте, административная часть сайта или любой другой раздел, доступ к которому мы хотим ограничить и предоставлять только по паролю. Для этого можно, конечно же, воспользоваться средствами сервера. Думаю, на любом современном хостинге есть функция паролирования директории, где можно создать пользователя, назначить ему пароль и, после паролирования директории, доступ к закрытому каталогу будет предоставлен только после правильного ввода логина и пароля. Но иногда хочется написать что-то самому, что-то быстрое, простое, но вместе с тем — надежное…

Время ролика: 31:32

Бесплатный курс по PHP программированию

Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC

В курсе 39 уроков | 15 часов видео | исходники для каждого урока

Вкратце всю работу с сессиями можно разделить на 3 этапа:

Открытие сессии. На всех страницах, где подразумевается работа с сессиями, обязательно должен быть осуществлен старт сессии функцией session_start().

Разрегистрирование сессионных переменных при помощи функции unset() и закрытие сессии функцией session_destroy().

Шаг 1

Итак, для нашей работы создадим 3 файла — Главная страница (index.php), Контакты (contact.php) и Админка (admin.php). Обращаю внимание на то, что расширение файла, к которому мы будем ограничивать доступ должно быть .php. Как Вы догадались, ограничивать доступ мы будем к файлу admin.php. Код всех файлов самый простой — это своеобразное меню в строку со ссылками на другие страницы, и под ним индивидуальный текст каждой страницы, чтобы мы могли отличать их друг от друга. Вот, к примеру, код индексной страницы:

p > a href = "index.php" > Главная / a > | a href = "contact.php" > Контакты / a > | a href = "admin.php" > Админка / a > / p >

Остальные страницы, как я сказал, отличаются от нее только текстом после тега линии. Я не стал делать полноценные страницы с мета-тегами, поскольку наша задача состоит только в ограничении доступа к некоей странице.

Шаг 2

Пока что мы свободно можем ходить по всем страницам, включая страницу админки. Как же мы ограничим к ней доступ? Каков вообще будет алгоритм? Мы будем делать следующее: в самом начале страницы мы будем проверять, есть ли нужная нам метка в сессии или, проще говоря, существует ли определенная сессионная переменная (также можно проверять равно ли значение сессионной переменной определенному значению). Если такой переменной нет, значит пользователь, запрашивающий эту страницу, не авторизован, а значит мы осуществим его редирект на страницу авторизации, где ему будет предложено заполнить форму с именем и паролем. Алгоритм предельно прост — реализуем его. Переходим к файлу admin.php, открываем в самом верху конструкцию PHP и напишем такой код:

Шаг 3

Теперь нам нужно создать страницу авторизации — enter.php. Для этого скопируем код, к примеру, страницы contact.php, создадим новый файл и вставим в него скопированный код. Файл сохраняем под именем enter.php. Теперь на этой странице напишем простенькую форму для ввода логина и пароля:

p > a href = "index.php" > Главная / a > | a href = "contact.php" > Контакты / a > | a href = "admin.php" > Админка / a > / p >

Шаг 4

Далее нам нужно написать на странице с формой ее обработчик, который будет принимать данные из формы и сравнивать, совпадают ли логин и пароль из формы с теми, которые есть у нас. Для этого откроем вверху страницы авторизации конструкцию PHP и начнем писать код. Для начала мы должны открыть сессию — ведь именно здесь мы будем создавать метку в сессии, если получены верные логин и пароль. На этой же странице мы будем хранить логин и пароль администратора. Обычно эти данные хранятся в базе данных (БД), но у нас будет только 1 пользователь (администратор), а потому хранить его данные для входа в БД не совсем рационально. Если же пользователей будет не один, т.е., мы, к примеру, пишем проект, в котором имеется регистрация, то, конечно же, без БД в таком случае обойтись будет сложно.

Иногда, для корпоративных порталов, актуально не заводить отдельный список пользователей, а производить авторизацию через контроллер доменов. Для этого в PHP есть набор специальных функций Облегчённый протокол доступа к каталогам (LDAP). В принципе там все написано, но рассмотрим простой пример. Надеюсь это будет полезно для тех, кто не особо знаком с особенностями работы контроллера домена. Здесь не будем рассматривать то, как передавать информацию серверу, просто предположим, что в POST запросе прилетают имя пользователя (username) и пароль (password) Итак, код с комментариями: 1. Набор опций (конфиг, так сказать)

//Полный путь к группе которой должен принадлежать человек,

//Собственно говоря фильтр по которому будем аутентифицировать пользователя

Курс предназначен для базовой подготовки пользователей, осуществляющих администрирование порталов, созданных на коробочной версии сервиса Битрикс24. Изучение курса позволяет освоить основные методы администрирования системы. Если вы хотите ознакомиться с тем как внедрить наш сервис в работу вашей компании, то для вас создан курс Внедрение корпоративного портала.

Курс предусматривает обучение по двум ролям администраторов: Администратор корпоративного портала и Администратор системы.

Администратор корпоративного портала - пользователь, осуществляющий текущее администрирование уже настроенного и сданного в эксплуатацию портала.

Разные роли созданы в связи с тем, что для администрирования настроенного и отлаженного корпоративного портала нет необходимости в работе профессионала высокого уровня. Вполне достаточно пользователя успешно изучившего данный курс в рамках роли Администратор КП.

При условии качественного изучения материалов курса, по его окончании специалист должен уметь:

настраивать модули системы;
использовать возможности интерфейса по управлению системой;
управлять доступом к системе, сайтами, пользователями, группами пользователей;
управлять содержимым портала;
работать с инструментами системы;

Начальные требования

Для прохождения курса необходимо:

наличие базовых навыков компьютерной грамотности и навыков работы с ОС Windows;
наличие представлений о WWW и организации доступа к веб-серверу;
базовые навыки установки и администрирования *nix-систем.

Если вам предстоит самостоятельная установка системы, то рекомендуется к изучению курс Установка и настройка.

Администратору системы будет полезно ознакомиться с курсом Разработчик Bitrix Framework, рассказывающем о принципах работы Bitrix Framework.

Примечание. Битрикс24 создан на основе платформы Bitrix Framework, на которой ранее был создан другой продукт "1С-Битрикс: Управление сайтом". В административной части системы сохранена терминология, относящаяся к этому продукту. Поэтому в текущем курсе понятие "сайт" нужно рассматривать как синоним слова "портал".

У нас часто спрашивают, сколько нужно заплатить

Курс полностью бесплатен. Изучение курса, прохождение итоговых тестов и получение сертификатов - ничего из этого оплачивать не нужно.

Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.

Баллы опыта

В конце каждого урока есть кнопка Прочитано! . При клике на неё в Вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:

уроке.

Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат - это если общее число набранных Вами баллов отличается от максимального на 1-2%.

Тесты и сертификат

После изучения курса вам будет предложено пройти тесты на сертификацию. При успешной сдаче линейки тестов на странице Моё обучение можно просмотреть результат обучения и загрузить сертификат в формате PDF.

Для преподавания оффлайн

Если данный курс берётся в качестве основы для оффлайного преподавания, то рекомендуемая продолжительность: 10 дней (70 академических часов).

Если нет интернета

iPhone:
FBReader
CoolReader
iBook
Bookmate

Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome

iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла - от 02.12.2021.

Читайте также: