Авторизация и аутентификация для всех

Отключение автоматической аутентификации в Internet Explorer

При разработке веб-приложений с анонимным доступом или отличной от Windows аутентификацией необходимо отключить автоматическую проверку подлинности. К примеру, это очень актуально при разработке приложений для SharePoint.  В принципе, все браузеры кроме Internet Explorer не поддерживают автоматическую авторизацию, потому это только для пользователей Internet Explorer.

В Internet Explorer по умолчанию включена поддержка интегрированной аутентификации пользователей. Потому для проверки работы приложений с анонимной аутентификацией нужно изменить настройку браузера, отключив встроенную проверку подлинности Windows. Это можно сделать в разделе «Свойства браузера / Дополнительно». Параметр для отключения – «Разрешить встроенную проверку подлинности Windows» (Рис.1).

Рис.1. Отключить встроенную проверку подлинности Windows

ПоделитьсяTвитнутьPinПоделиться0 Поделились

• 29 апреля 2016, Alexey
• Sharepoint
• Тэги: Internet Explorer, sharepoint, Списки Sharepoint
• Комментарии: (0)

Создайте федерацию в облаке

Консоль управления CLI API

Чтобы создать федерацию в IAM:

1. Откройте страницу каталога в консоли управления.

2. В меню слева выберите вкладку Федерации.

3. Нажмите Создать федерацию.

4. Задайте имя федерации. Имя должно быть уникальным в каталоге.

5. При необходимости добавьте описание.

6. В поле Время жизни cookie укажите время, в течении которого браузер не должен требовать у пользователя повторной аутентификации.

7. В поле IdP Issuer укажите ссылку в формате http://<ADFS>/adfs/services/trust, где <ADFS> — это FQDN вашего AD FS сервера.

8. В поле SSO метод выберите POST.

9. В поле Ссылка на страницу для входа в IdP укажите ссылку в формате https://[ADFS]/adfs/ls/, где <ADFS> — это FQDN вашего AD FS сервера.

10. Включите опцию Автоматически создавать пользователей, чтобы аутентифицированный пользователь автоматически добавлялся в облако. Эта опция упрощает процесс заведения пользователей, но созданному таким образом пользователю по умолчанию назначается только роль : он не сможет выполнять никаких операций с ресурсами в этом облаке. Исключение — те ресурсы, на которые назначены роли системной группе allUsers или allAuthenticatedUsers.

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

Если у вас еще нет интерфейса командной строки , установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

1. Посмотрите описание команды создания федерации:

   $ yc iam federation create --help

2. Создайте федерацию:

   $ yc iam federation create --name my-federation \ --auto-create-account-on-login \ --cookie-max-age 12h \ --issuer "" \ --sso-binding POST \ --sso-url ""

   Где:

   • name — имя федерации. Имя должно быть уникальным в каталоге.

   • auto-create-account-on-login — флаг, активирующий автоматическое создание новых пользователей в облаке после аутентификации на IdP-сервере. Эта опция упрощает процесс заведения пользователей, но созданному таким образом пользователю по умолчанию назначается только роль : он не сможет выполнять никаких операций с ресурсами в этом облаке. Исключение — те ресурсы, на которые назначены роли системной группе allUsers или allAuthenticatedUsers.

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

   • cookie-max-age — время, в течении которого браузер не должен требовать у пользователя повторной аутентификации.

   • issuer — идентификатор IdP-сервера, на котором должна происходить аутентификация.

     Укажите ссылку в формате http://<ADFS>/adfs/services/trust, где <ADFS> — это FQDN вашего AD FS сервера.

   • sso-url — URL-адрес страницы, на которую браузер должен перенаправить пользователя для аутентификации.

     Укажите ссылку в формате https://[ADFS]/adfs/ls/, где <ADFS> — это FQDN вашего AD FS сервера.

   • sso-binding — укажите тип привязки для Single Sign-on. Большинство поставщиков поддерживают тип привязки POST.

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

2. Создайте файл с телом запроса, например :

   { "folderId": "<ID каталога>", "name": "my-federation", "autocreateUsers": true, "cookieMaxAge":"43200s", "issuer": "", "ssoUrl": "", "ssoBinding": "POST" }

   Где:

   • folderId — идентификатор каталога.

   • name — имя федерации. Имя должно быть уникальным в каталоге.

   • autocreateUsers — флаг, активирующий автоматическое создание новых пользователей в облаке после аутентификации на IdP-сервере. Эта опция упрощает процесс заведения пользователей, но созданному таким образом пользователю по умолчанию назначается только роль : он не сможет выполнять никаких операций с ресурсами в этом облаке. Исключение — те ресурсы, на которые назначены роли системной группе allUsers или allAuthenticatedUsers.

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

   • cookieMaxAge — время, в течении которого браузер не должен требовать у пользователя повторной аутентификации.

   • issuer — идентификатор IdP-сервера, на котором должна происходить аутентификация.

     Укажите ссылку в формате http://<ADFS>/adfs/services/trust, где <ADFS> — это FQDN вашего AD FS сервера.

   • ssoUrl — URL-адрес страницы, на которую браузер должен перенаправить пользователя для аутентификации.

     Укажите ссылку в формате https://[ADFS]/adfs/ls/, где <ADFS> — это FQDN вашего AD FS сервера.

   • ssoBinding — укажите тип привязки для Single Sign-on. Большинство поставщиков поддерживают тип привязки POST.

3. Создайте федерацию с помощью метода create:

   $ curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <IAM-токен>" \ -d '@' \ { "done": true, "metadata": { "@type": "", "federationId": "ajeobmje4dgj0belagb9" }, ...

   В ответе, в свойстве federationId, будет указан идентификатор созданной федерации, сохраните его. Этот идентификатор понадобится на следующих шагах.

Настройка авторизации

Чтобы настроить авторизацию, надо точно так же, как мы делали при настройке аутентификации, переопределить метод configure (), только теперь с другим аргументом HttpSecurity:

@EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { //другие методы @Override protected void configure (HttpSecurity http) throws Exception { () .antMatchers («/admin/**»).hasRole ( «ADMIN») .antMatchers («/user/**»).hasAnyRole («USER», «ADMIN») .antMatchers («/**»).permitAll () .and ().formLogin (); } }

Именно этот объект HttpSecurity и нужно настраивать. Создавать его как бин не надо, его создает Spring Security, а мы получаем к нему доступ из метода configure (HttpSecurity http).

Как мы видели в прошлой статье, по умолчанию Spring Security дает доступ к любому url любому аутентифицированному пользователю. Иначе говоря, если хочешь попасть на url, перенаправляешься на форму ввода пароля, и только после этого попадаешь на url.

Переопределив метод configure (HttpSecurity http), мы немедленно отменили поведение по умолчанию. Теперь внутри переопределенного метода все требуется задать заново вручную (с небольшими нововведениями).

Мы по очереди перечисляем возможные url и задаем права доступа к ним (точнее, в нашем примере – роли).

Перечисление url

Итак:

()

Это строкой мы говорим предоставить разрешения для следующих url.

Далее мы перечисляем не сами url (поскольку их может быть слишком много), а шаблоны. Шаблоны url задаются с  помощью класса AntPathRequestMatcher .

Перечислять шаблоны надо в порядке от самых узкоохватывающих до широкоохватывающих:

.antMatchers («/admin/**»).hasRole («ADMIN») .antMatchers («/user/**»).hasAnyRole («USER», «ADMIN») .antMatchers («/**»).permitAll ()

Здесь шаблон:

/** означает любой url /admin/** означает любые, в том числе вложенные url, начинающиеся с /admin

Например, следующие три url подпадают под  шаблон /admin/**:

/admin /admin/page1 /admin/aaa/bbb

Если в коде начать перечисление с всеобъемлющего шаблона  /**, то перебор на нем остановится (так как любой url, в том числе /admin) соответствует шаблону /** , а значит всем будет разрешен доступ. Именно поэтому начинать нужно с узкоохватывающих шаблонов.

Настройка доступа (роли, разрешения)

Наконец, к главному. После шаблона в каждой строке указывается кому разрешен доступ: всем пользователям (метод permitAll () разрешает доступ всем, в том числе неаутентифицированным пользователям) или пользователям с определенной ролью – метод hasRole (“ADMIN”) (либо ролями).

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

Можно было задать доступ с помощью разрешений, результат был бы аналогичный:

@Override protected void configure (HttpSecurity http) throws Exception { () .antMatchers («/admin/**»).hasAuthority («ROLE_ADMIN») .antMatchers («/user/**»).hasAnyAuthority («ROLE_USER», «ROLE_ADMIN») .antMatchers («/**»).permitAll () .and ().formLogin (); }

Еще такой есть полезный метод:

.authenticated () — разрешает доступ всем аутентифицированным пользователям

Страница ввода пароля

Наконец, страница логина теперь генерироваться не будет, чтобы ее вернуть, допишем строку:

.and ().formLogin ();

Если пользователь не аутентифицирован (в данном случае так будет, если в запросе либо отсутствует кукис JSESSIONID, либо он неправильный), то выполняется редирект на страницу ввода логина и пароля.

Ввод логина и пароля в форму считается аутентификцией типа Form-Based, что означает, что имя и пароль приходят в  POST-запросе в параметрах username и password (такие имена параметров по умолчанию используются в Spring Security). То есть когда пользователь попадет на страницу логина и введен туда данные, на сервер пойдет новый запрос, в котором данные будут передаваться в этом самом POST.

Чтобы задать аутентификацию типа Http Basic, строка в коде должна быть такая:

.and ().httpBasic ();

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

Authorization: Basic base64 (usename:password)

Это устаревший и небезопасный способ.

Но суть в том, что обе эти строки указывают Spring Security, как именно он должен брать из запроса имя пользователя и пароль.

Не стоит путать аутентификацию In-Memory (рассмотренную в предыдущей статье) с аутентификациями типа Form-Based  и Http Basic.  Последние две безотносительно Spring Security определяют, как именно передается в запросе имя/пароль с клиента на сервер, то есть в какой части запроса хранятся эти данные – в заголовке, в теле запроса и т.д. А In-Memory – это тип аутентификации в Spring Security (один из), который задает, как пользователи хранятся на стороне сервера (в базе, настройках, коде… ), как и откуда их достать, чтобы потом сравнить с переданными в запросе именем и паролем.

Советы по защите вашей сети

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

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

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

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

Проблема входа в систему

То, что происходит после того, как OAuth 2.0 установил способ доступа к сторонним API, заключается в том, что приложение также требуется регистрировать пользователей у себя. Используя наш пример: HireMe123 нужно, чтобы пользователь MyCalApp мог залогиниться, используя свою учетную запись MyCalApp, даже несмотря на то, что он не был зарегистрирован в HireMe123.

Но, как мы упоминали выше, OAuth 2.0 предназначен только для делегированного доступа. Это не протокол аутентификации. Но это не помешало людям попытаться использовать его и для аутентификации, и это представляет проблему.

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

Если HireMe123 предполагает успешный вызов API MyCalApp с токеном доступа, достаточным что бы пользователь считался аутентифицированным, у нас возникают проблемы, поскольку у нас нет способа проверить, был ли выдан токен доступа правильному пользователю.

Например:

• Кто-то мог украсть токен доступа у другого пользователя
• Маркер доступа мог быть получен от другого клиента (не HireMe123) и введен в HireMe123

Это называется запутанной проблемой делегирования. HireMe123 не знает, откуда взялся этот токен и кому он был выдан. Если мы помним: аутентификация — это проверка того, что пользователь — это тот, кем он себя заявляет. HireMe123 не может знать это из-за того, что он может использовать этот токен доступа для доступа к API.

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

Ошибки аутентификации при подключении к беспроводным сетям

Подключаясь к беспроводной сети, пользователь также проходит через процесс аутентификации. Существует несколько способов проверки подлинности такого типа. Они зависят от настроек роутера, количества абонентов, вида беспроводной сети (домашняя, общественная, корпоративная). Чаще всего используется тип шифрования WPA-PSKWPA2-PSK2 mixed. Он является достаточно защищенным и подходит для применения в различных видах сетей. Для большей безопасности многие частные организации используют шифрование, где каждый пользователь имеет индивидуальный пароль, привязанный к ПК.

Ошибки аутентификации чаще всего возникает при несоответствии вида шифрования и набранной парольной фразы. Пути решения проблемы будут отличаться для пользователей ПК и владельцев мобильных телефонов.

Как убрать ошибки аутентификации на компьютере

Если после введения ключевой фразы вы получаете уведомление об ошибке аутентификации, то в первую очередь вам необходимо проверить следующее:

• правильность написания ключевой фразы (возможно, была допущена ошибка или включена неверная раскладка);
• отключен ли Caps Lock;
• верно ли выбрана беспроводная сеть, к которой вы подключаетесь.

Как узнать пароль от Wi-Fi?

Если вы забыли свою парольную фразу, то узнать ее можно в настройках роутера. Для этого подключитесь к нему при помощи кабеля и откройте любой интернет-браузер. Напишите IP маршрутизатора в адресной строке. Посмотреть его можно в инструкции или на корпусе роутера. Еще один способ узнать IP-адрес — использовать командную строку. Для этого используйте комбинацию Win+R и в появившемся окне введите команду «CMD». Запустится командная строка, где вам необходимо будет ввести «ipconfig». Строка «Основной шлюз» является требуемым IP-адресом.

Введите IP-адрес в адресной строке браузера. В появившемся окне введите логин и пароль для входа (по умолчанию admin и admin соответственно). В меню выберите пункт «Расширенные настройки» и перейдите в подраздел «Wi-Fi». Найдите параметры безопасности — именно здесь можно обнаружить тип шифрования, название сети и пароль.

Пароль введен правильно, но войти в сеть не удается

Аутентификация может не состояться при сбое самого роутера. Решается простой перезагрузкой девайса. В таких ситуациях также рекомендуется проверить канал роутера. Для этого в настройках WiFi перейдите в раздел «Основные настройки», а там — в подпункт «Канал». Желательно установить значение «Автоматически».

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

Проблемы с аутентификацией на мобильном устройстве

Процесс аутентификации на мобильном девайсе происходит следующим образом:

1. Устройство производит поиск сетей, после чего владелец телефона или планшета выбирает необходимый Wi-Fi.
2. Пользователь вводит пароль беспроводной сети.
3. Статус соединения изменяется: подключение, аутентификация, сохранено (с указанием вида шифрования сети).

Что значит уведомление «Ошибка аутентификации»? Данное сообщение показывает, что проблема кроется в неправильно введенном пароле или параметрах безопасности роутера. Неработающий Wi-Fi после уведомления «Сохранено» свидетельствует о неполадках самой беспроводной сети.

Как исправить?

Прежде чем изменять параметры роутера, убедитесь, что пароль введен правильно, у вас не включен Caps Lock или кириллица/латынь. Только после этого обращайтесь к настройкам Wi-Fi:

• убедитесь, что режим Wi-Fi сети поддерживается — попробуйте переключить его на  b/g;
• смените регион — попробуйте переключить Россию на США и обратно;
• измените тип шифрования: если у вас стоит WPA2-Personal, то замените его на WPA с шифрованием AES;
• если ошибка аутентификации сочетается со слабым сигналом беспроводной сети, то попробуйте выбрать свободный канал и расширить его на 20 МГц.

Еще один вариант, который может вам помочь — это специальное приложение для устройств Android — Wi-Fi Fixer (доступен для скачивания в Google Play). Оно автоматически исправляет ошибки беспроводной сети и позволяет вам подключиться к роутеру при ошибке аутентификации.