Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java EE (J2EE) и Spring > Веб-сервисы и токены, аутентификация через STS


Автор: Key 28.5.2010, 23:01
Пробую реализовать аутентификацию для веб-сервисов через токены.

Есть сервис, стандартный STS (Security Token Service), который генерирует токены. У него есть методы реквеста, валидации, инвалидации и renew токенов. Я использую Axis2, но такие 
сервисы есть у всех популярных библиотек. 

Он у меня генерит SAML 2.0 токены, так как в гугле они в основном попадались =) 
это XML где записаны дата создания, срок действия токена, различные аттрибуты юзера, для которого генериться токен (имя, фамилия и т.п.) (CLAIMS)

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


Так вот, не подскажите как реализовать такую архитектуру. 

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

STS сервис лезет в базу юзеров и генерит токен. 
Для доступа к STS сервису я использую стандартный STSClient для аксиса, который просто использует ServiceClient.

А вот дальше непонятно что делать. Я так понял нужно настроить спец Policy для защищенного сервиса. В примерах используют елемент IsuedToken в policy файле сервиса, в котором указан 
адрес STS сервиса. Я конфигурю эти полиси для веб-сервиса и клиента, но при запросе методов 
защищенного сервиса, оно лезет на STS за токеном. Как сделать чтоб оно использовало токен 
полученый ранее? Передавать токен в хидере SOAPа? Если оно увидет его оно за ним не 
полезет? 

Потом при получении токена как нужно делать его валидацию в защищенном сервисе? Надо вытаскивать его с 
СОАП хидера и отправлять STS сервису запрос валидации? 

А чтоб получить атрибуты которые записаны в токене нужно тоже его вытаскивать с хидера и парсить?

Совсем запутался с этими токенами =)

Какая тут правильная архитектура? как стандартно делают? 

Клиент должен запрашивать токен передавая логин и пароль или использовать сразу сервис чтоб он сам отправил запрос за токеном? Но во втором случае непонятно как передать логин и 
пароль STS сервису, чтоб вставить в токен дополнительные атрибуты для юзера и проверить есть ли юзер в базе. 

И как правильно делать валидацию токенов?

И еще вопрос, когда я в клиенте получил сгенереный токен, его нужно записать в память и использовать пока не истечет его срок действия, а потом запрашивать опять?

Автор: Key 29.5.2010, 00:46
Вот нашел как оно должно быть в одном из блогов

Цитата

1. Since the client needs to obtain a token before talk to the service, it will make a WS-Trust call to the STS sending some kind of credentials. It could be Windows credentials, a X509 certificate, username and password or maybe another token.

2. The STS will authenticate the caller and probably will output some claims about him. These claims might come from some repository like a database or AD. If the client is using Windows credentials, maybe the claims will be the groups the user belongs, the email and the full name. If the client is using username and password, the claims could be the roles stored in a database table. However, the claims could be anything you want that will be used later to perform access checks on the service.

3. The response is sent to the client containing an RSTR (Request Security Token Response) that will contain the requested security token with the claims. This token can be encrypted so only the service can decrypt it. For doing that, the STS will use the public key of the service certificate. The token will be also signed by the STS to avoid untrusted issuers. To sign the token, the STS will use a private key.

4. Finally, the client calls the service using the token obtained in 3. The service will only accept tokens of trusted issuers. Since there is a trust relationship between our STS and the service, the latter will have the public key of the STS that will allow him to check the signature of the token.


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

Осталось только с 4 пунктом разобраться. Чтоб он не лез к STS за токеном я так понял нужно вставлять токен в СОАП и в элементе IssuerAddress в policy ставить левый адрес и ссылку на токен в этом же соапе, только осталось найти как это сделать =) 
И на сколько я понял в Axis2 нужно всетаки выдирать атрибуты в токене с соап хидера, после того, как он будет раскодирован и проверять его на валидность таким же способом. Что-то не очень красиво =) Посмотрим что выйдет.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)