Google Apps as SAML IdP

Ознакомился с возможностями Гугла в качестве Identity Provider по протоколу SAML.
Вкратце: не впечатлён. Понимаю теперь, почему ЖЖ, StackOverflow и прочие, тысячи их, используют oAuth.

Недостатки такие:

• Identity сайта / приложения, желающего опознавать гугл-юзеров по SAML, криптографически никак не проверяется, запросы не подписываются, да и возможности залить соответствующий ключ Гуглу для проверки нету.
  Единственное, что проверяется - что строка "Entity ID", указанная Гуглу при регистрации приложения, соответствуюет полю <saml:Issuer> в запросе. Есть совпадение - и ладушки.
  
  То есть в принципе фишинговый сайт может получить имена аккаунтов заходящих на него гугл-юзеров, и ещё немного дополнительной информации (см. ниже про атрибуты). Пароли, конечно, не получит.
  
  Ответ, правда, подписывается честь по чести. Возможности зашифровать его, впрочем нету, да и нечем - ключ, как сказано выше, указать негде.

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

• Недостаток, несколько смягчающий два предыдущих: очень убогие возможности по части юзерских атрибутов, которые можно прописать в ответе запрашивающему приложению. Можно указать имя, фамилию, e-mail, номер телефона или адрес (а вот это для фишеров уже интересно!), а из корпоративной информации - название должности, департамент и cost center (что бы это не значило). Фсё. Группы, к которым юзер принадлежит в Google Apps, указать никак нельзя, к глубокому моему удивлению.
  ADFS по этому критерию кроет Гугл, как бык овцу.

• А да, и касается вся эта бодяга исключительно юзеров G-Suite (Google Apps). Обычные юзеры, с @gmail.com в названии, могут не волноваться.

Недостаток у oAuth про сравнению с SAML, правда, тоже есть: он требует от приложения знать конкретный API, от которого оно будет получать информацию после получения юзерского согласия - гугловский ли, фейсбучный или твиттеровский. SAML более стандартизирован (и оттого сложен, как моя жизнь). Хотя при "феодальной" модели, при которой identity provider'ов для 90% сетевого населения можно пересчитать по пальцам, этот недостаток не очень-то заметный.

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

И наконец, однозначное преимущество SAML в том, что он не требует прямой связи между приложением и IdP. Сайт с приложением может сидеть во внутренней сети и никуда из неё не выходить, а IdP - в Интернете (тот же Гугл), и весь обмен между ними будет проходить через юзерский браузер.


А вот чем очень приятно впечатлён, это опен-сорсной библиотекой Keycloak, которую использовал, чтобы встроить SAML  в свою маленькую Java-апликацию. Вставляешь servlet filter - и готово, можешь считать юзерский аккаунт и, положим, департамент, через привычные, милые сердцу вызовы getUserPrincipal() и isUserInRole(). Причём, поскольку это стандартный servlet filter, можешь гонять свою апликашку на любом Java-сервере - хошь Tomcat, хошь Glassfish, хошь JBoss.