OpenID в Web-додатках на Java: Частина 2. Створення провайдера OpenID для забезпечення єдиної аутентифікації

OpenID в Web-додатках на Java

Серія контенту:

Цей контент є частиною # з серії # статей: OpenID в Web-додатках на Java

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=openid+в+web-приложениях+на+java

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: OpenID в Web-додатках на Java

Слідкуйте за виходом нових статей цієї серії.

OpenID поступово завойовує все більше визнання в якості надійного засобу ідентифікації і аутентифікації користувачів, що дозволяє їм звертатися до Web-сайтів та інших online-ресурсів, здатним розпізнавати їх ідентифікатори. В попередній статті серії було приведено введення в специфікацію аутентифікації OpenID, а також розповідалося про те, як її можна інтегрувати в Web-додатки на Java за допомогою бібліотеки openid4java.

Протягом більшої частини попередньої статті основна увага приділялася клієнтам OpenID (OpenID Relying Party або RP), які представляють собою online-ресурси, наприклад, Web-сайти або файли MP3, використовують OpenID для реєстрації і аутентифікації користувачів. Іншим компонентом специфікації аутентифікації OpenID є провайдери (OpenID Provider або OP). Вони надають користувачам ідентифікатори і дозволяють аутентифицироваться для звернення до Web-ресурсів, що підтримує OpenID.

В даний час існує безліч провайдерів OpenID (наприклад, myOpenID, який ми використовували при реєстрації в демонстраційному додатку в попередній статті ), Тому, як правило, немає необхідності винаходити велосипед.

Прикладом ситуації, при якій вам може знадобитися власний OP, послужить кластер з декількох додатків, що утворюють довірчу мережу з доступом до єдиного ресурсу. У цьому випадку має сенс створити безпечну, замкнуту (closed loop) систему. Це дозволить користувачем аутентифицироваться один раз для отримання доступу до всіх програм в кластері. Для забезпечення такої єдиної аутентифікації можна виділити один додаток, яке буде грати роль OP.

У цій статті ми розглянемо питання створення провайдера OpenID для забезпечення безпечного доступу до безлічі додатків замкнутої системи. Спочатку будуть розглянуті переваги і структура єдиної системи аутентифікації, а потім - реалізація простого провайдера OpenID. Як і в попередній статті, ми будемо використовувати бібліотеку openid4java реалізації основних функцій системи аутентифікації. Це гарантує, що наш провайдер буде відповідати специфікації OpenID.

Єдина аутентифікація

У ряді випадків краще використовувати комплекс додатків, що володіють різною функціональністю, ніж проектувати монолітну систему, яка надає всі необхідні можливості. Подібні комплекси (або кластери) часто лежать в основі B2B-систем, причому кожен з бізнес-партнерів вносить свій внесок в систему, тим самим підвищуючи її комерційну цінність.

Однак подібна архітектура ускладнює аутентифікацію, зокрема підхід, при якому кожен додаток самостійно аутентифікує користувачів, перестає працювати, принаймні з точки зору останніх.

У кластерах, що використовують аутентифікацію на основі OpenID, кожне з додатків може делегувати роботу по ідентифікації користувачів єдиного провайдера (OP). Таким чином, додатки можуть бути впевнені в захищеності своїх ресурсів і функціональності, а користувачі можуть насолоджуватися усіма зручностями централізованої аутентифікації.

Далі ми більш детально розглянемо всі компоненти єдиної системи аутентифікації. Зверніть увагу, що архітектура, обговорювана нижче, ґрунтується на демонстраційному додатку з попередньої статті .

Клієнт OpenID (OpenID Relying Party або RP)

Як ви пам'ятаєте, клієнти OpenID - це Web-сайти або інші online-ресурси, які вимагають захищеного доступу до їхнього вмісту. Клієнти виконують аутентифікацію користувачів, використовуючи провайдери OpenID (OP). Вони також можуть використовувати розширення Simple Registration (SReg) або Attribute Exchange (AX), щоб пристрій запитував реєстрації або отримання інформації про користувачів (див. Розділ ресурси ). Клієнти виконують запити за допомогою SReg або AX в момент направлення користувача до OP для аутентифікації, наприклад за допомогою бібліотеки openid4java.

Трохи про SReg

У демонстраційному додатку, розглянутому в попередній статті під назвою OpenID в Web-додатках на Java. Частина 1 , Використовувалося розширення Simple Registration, щоб пристрій запитував інформації про користувача у провайдера. Зверніться до неї, якщо вас цікавить детальніша інформація про це розширенні. У додатку, обговорюваному нижче, використовується інше розширення - Attribute Exchange (AX), що підтримує більш складні сценарії обміну даними з провайдером.

Провайдер OpenID (OP)

Провайдер OpenID надає сервіс для аутентифікації всіх програм кластера. Після того як користувач успішно аутентифікований за допомогою бібліотеки openid4java, OP обробляє всі запити до розширень SReg і AX, отримані від RP. Як буде показано нижче, OP займає центральне місце в системі єдиної аутентифікації програмних кластерів.

Створення провайдера OpenID

У попередній статті було продемонстровано використання бібліотеки openid4java для включення можливостей RP в Web-додаток, написаний на Java. У цій статті застосовується аналогічний підхід до розробки провайдера. Бібліотека openid4java перетворює процес створення OP, що задовольняє специфікації OpenID, в легке вправу, дозволяючи користуватися всіма перевагами готової інфраструктури OpenID.

демонстраційне додаток

В даному додатку демонструється спільна робота клієнтів і провайдера OpenID з метою захисту ресурсів від несанкціонованого доступу. Додаток підтримує такий сценарій роботи.

Користувач робить спробу звернення до захищеного ресурсу.
RP звертається до OP із запитом на аутентифікацію користувача.
OP аутентифікує користувача, якщо той раніше не виконав вхід в систему.
RP визначає, чи має аутентіфіцированний користувач право на звернення до ресурсу.

Додаток включає реалізацію як клієнта, так і провайдера OpenID, демонструючи їх взаємодія. У реальних системах ці компоненти, як правило, відносяться до різних програм, однак в даному випадку вони поєднані з міркувань наочності.

Приклади коду демонстраційного додатки

У прикладах коду, наведених нижче, показані виклики методів API бібліотеки openid4java, виконувані провайдером і клієнтами OpenID. Зверніть увагу, наскільки невеликий обсяг коду потрібно даному додатку, іншими словами, наскільки сильно openid4java полегшує життя розробникам. При цьому клієнтський код аналогічний тому, який розглядався в першій статті , Тому зверніться до неї, якщо вас цікавлять деталі реалізації RP. Ми ж зупинимося лише на кількох моментах, пов'язаних з AX (це розширення не використовувалося в попередній статті).

Аналогічно до попереднього додатком, інтерфейс також створений з використанням бібліотеки Wicket. Щоб мінімізувати залежність додатки від Wicket, код провайдера, який звертається до openid4java, було винесено в окремий клас OpenIdProviderService в пакеті com.makotogroup.sample.model .

Клас OpenIdProviderService містить ряд методів, які використовують різні можливості бібліотеки openid4java:

getServerManager () налаштовує і повертає посилання на клас ServerManager бібліотеки openid4java;
getOpEndpointUrl () повертає URL кінцевої точки, в яку повинні надходити запити від клієнтів OpenID;
processAssociationRequest () використовує openid4java для обробки запиту на установку з'єднання з клієнтом OpenID;
sendDiscoveryResponse () відправляє клієнту відгук на запит виявлення;
createAuthResponse () створює повідомлення типу AuthResponse, що відправляється клієнтові у відповідь на запит на аутентифікацію;
buildAuthResponse () - центральний метод, що обробляє запити до розширень SReg і AX.

Для запуску програми виконайте команду Ant [REF], зберіть WAR-архів, скопіюйте його в директорію webapps в Tomcat, а потім запустіть сам Tomcat.

Аутентифікація OpenID: крок за кроком

Після того як користувач звернувся до захищеного ресурсу всередині клієнта OpenID, тому необхідно упевнитися, що користувач є саме тим, за кого себе видає (тобто аутентифицировать), а потім вирішити, чи слід надавати йому доступ (тобто авторизувати) . У цій статті основну увагу приділяється аутентифікації, тому якщо користувач був успішно аутентифікований провайдером OpenID, йому буде надано доступ до ресурсу. У реальній системі RP, як правило, виконає перевірку прав доступу.

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

Далі ми докладно розглянемо кожен з кроків.

Навіщо потрібно розширення AX?

Можливо, ви помітили, що демонстраційний додаток використовує два розширення (SReg і AX) для обміну даними між провайдером і клієнтом OpenID (див. Розділ ресурси ). Обидва цих розширення потрібні для ефективної взаємодії OP і RP. При цьому SReg підтримує тільки обмін значеннями обмеженого числа атрибутів, в той час як AX може використовуватися для обміну фактично будь-якою інформацією, яка може бути описана у вигляді атрибутів як на стороні OP, так і RP. У програмних кластерах, подібних до нашого, може трапитися так, що кожен додаток-клієнт буде використовувати власне спеціалізоване розширення OpenID (vendor extension). Це ще один спосіб реалізації взаємодії між провайдером і клієнтами. Детальніше AX обговорюється в наступних розділах статті.

Запит на доступ до захищеного ресурсу

демонстраційне додаток включає єдиний захищений ресурс. Якщо після запуску додатка звернутися до RP за адресою http: // localhost: 8080 / openid-provider-sample-app /, то ви побачите сторінку, показану на малюнку 1.

Малюнок 1. Головна сторінка демонстраційного додатки

OpenID в Web-додатках на Java Серія контенту: Цей контент є частиною # з серії # статей: OpenID в Web-додатках на Java https://www

При натисканні на посилання буде виконаний код, наведений у лістингу 1.

Лістинг 1. Клас головної сторінки додатка, що містить захищений ресурс

package com.makotogroup.sample.wicket; . . . public class OleMainPage extends WebPage {public OleMainPage () {add (new OleMainForm ( "form")); } Public class OleMainForm extends Form {public OleMainForm (String id) {super (id); add (new PageLink ( "openIdRegistrationPage", new IPageLink () {public Page getPage () {return new OpenIdRegistrationPage ();} public Class <? extends WebPage> getPageIdentity () {return OpenIdRegistrationPage.class;}})); }}}

Зверніть особливу увагу на рядки, виділені жирним шрифтом в лістингу 1. Після натискання на посилання Wicket перенаправляє користувача до ресурсу OpenIdRegistrationPage. У цей момент викликається конструктор класу OpenIdRegistrationPage, який виконує наступні функції:

відіграє роль точки входу для початкового виклику;
відіграє роль об'єкта зворотного виклику, який отримує управління в разі успішної аутентифікації користувача провайдером.

При первинному виклику класу він не отримує на вхід ніяких параметрів (PageParameters) від Wicket. Це означає, що користувач повинен бути спрямований до провайдера для аутентифікації.

Виявлення провайдера клієнтом

Перед тим як почати взаємодію, RP повинен виконати операцію виявлення провайдера. З точки зору розробника, в цьому немає нічого складного (завдяки openid4java), але цей крок дуже важливий, тому має сенс розглянути його поетапно.

Нижче показаний фрагмент коду RP для відправки запиту на виявлення. Він знаходиться в конструкторі класу OpenIdRegistrationPage.

DiscoveryInformation discoveryInformation = RegistrationService.performDiscoveryOnUserSuppliedIdentifier (OpenIdProviderService.getOpEndpointUrl ());

У цьому коді можна виділити два моменти.

Виявлення провайдера по URL кінцевої точки.
Установка з'єднання (асоціювання) RP і OP. Детальний розгляд обміну ключами по алгоритму Діффі-Хеллмана і інших аспектів асоціювання приведено в першій статті .

Далі настав час перейти до розгляду того, як OP обробляє запити на виявлення з боку клієнтів.

Відгук на запит виявлення

Як ви пам'ятаєте, бібліотека використовується як клієнтською частиною програми, так і провайдером. Внаслідок цього в процесі виявлення RP посилає порожній запит по URL кінцевої точки провайдера. Кінцева точка (endpoint) - це URL, за яким OP приймає всі клієнтські запити і, зрозуміло, він повинен включати обробник запиту на виявлення. Якщо ви заглянете всередину методу OpenIdProviderService.getOpEndpointUrl (), то побачите, що в даному додатку адресою кінцевої точки є http: // localhost: 8080 / openid-provider-sample-app / sample / OpenIdLoginPage.

У момент відправки порожнього запиту до провайдера Wicket створює екземпляр класу OpenIdLoginPage, викликаючи його конструктор, показаний в лістингу 2.

Лістинг 2. Точка входу провайдера

public OpenIdLoginPage (PageParameters parameters) throws IOException {super (parameters); if (parameters.isEmpty ()) {// Порожній запит розцінюється як запит на виявлення OpenIdProviderService.sendDiscoveryResponse (getResponse ()); . . .

Зверніть увагу, що отримуючи на вхід порожній запит, провайдер робить висновок, що це запит на виявлення. В процесі обробки він створює документ XRDS і відправляє його клієнту.

Код методу sendDiscoveryRequest () приведений в лістингу 3.

Лістинг 3. Обробка запиту на виявлення

public static void sendDiscoveryResponse (Response response) throws IOException {// response.setContentType ( "application / xrds + xml"); OutputStream outputStream = response.getOutputStream (); String xrdsResponse = OpenIdProviderService.createXrdsResponse (); // outputStream.write (xrdsResponse.getBytes ()); outputStream.close (); }

Документ XRDS необхідний для коректного функціонування openid4java на стороні RP. Для стислості деталі вмісту цього документа опущені; якщо вас цікавлять подробиці, завантажте вихідний код демонстраційного додатки .

Отримавши XRDS-документ від OP, клієнт OpenID робить висновок, що коректний провайдер для аутентифікації даного користувача знайдений. Далі RP створює і відправляє провайдеру запит на аутентифікацію.

Запит на аутентифікацію користувача

RP взаємодіє з провайдером, щоб визначити результат аутентифікації користувача. Послідовність викликів методів, які виконуються конструктором на стороні RP, приведена в лістингу 4.

Лістинг 4. Код клієнта, що перенаправляє користувача до OP для аутентифікації

DiscoveryInformation discoveryInformation = RegistrationService.performDiscoveryOnUserSuppliedIdentifier (OpenIdProviderService.getOpEndpointUrl ()); MakotoOpenIdAwareSession session = (MakotoOpenIdAwareSession) getSession (); session.setDiscoveryInformation (discoveryInformation, true); AuthRequest authRequest = RegistrationService.createOpenIdAuthRequest (discoveryInformation, RegistrationService.getReturnToUrl ()); getRequestCycle (). setRedirect (false); getResponse (). redirect (authRequest.getDestinationUrl (true));

Спочатку RP звертається до OP за адресою кінцевої точки. Цей виклик може виглядати дещо дивно, проте не забувайте, що ми розглядаємо випадок програмного кластера, в якому в ролі провайдера виступає один з додатків. Таким чином, з точки зору RP, аутентифікація користувача зводиться просто до виявлення провайдера, після чого openid4java самостійно створить всі об'єкти, необхідні для взаємодії з ним. Безпосередньо процес аутентифікації буде виконуватися всередині провайдера.

Далі RP отримує посилання на Wicket-об'єкт типу Session і зберігає в ньому екземпляр DiscoveryInformation, отриманий від openid4java, для подальшого використання. Я створив спеціальний клас MakotoOpenIdAwareSession, успадкований від Session, що полегшує збереження об'єктів в сесії.

На наступному кроці RP створює запит на аутентифікацію, використовуючи раніше отриманий об'єкт типу DiscoveryInformation. Цей об'єкт необхідний для вказівки Wicket, за якою адресою слід перенаправити користувача для аутентифікації.

Поки всі виклики повинні бути вам знайомі по першій статті серії. Вони розглядаються повторно тому, що архітектура демонстраційного додатки для цієї статті разюче відрізняється від тієї, що використовувалася раніше. Крім того, нижче будуть продемонстровані виклики, що виконуються на стороні провайдера, тому повторення коду RP допоможе вам скласти обидві частини воєдино.

Отже, на цьом етапі RP очікує ВІДПОВІДІ від провайдера на свой запит на аутентіфікацію. Перед тим як перейти до наступного кроку, варто докладніше розглянути роль, яку відіграє розширення Attribute Exchange в процесі аутентифікації користувача.

Розширення OpenID Attribute Exchange

У попередній статті було коротко розглянуто розширення Simple Registration (SReg), що дозволяє клієнтам і провайдерам OpenID обмінюватися даними, тип яких описується в специфікації SReg. Однак якщо ви заглянете всередину методу createOpenIdAuthRequest (), то помітите, що в даному додатку RP використовує інше розширення, а саме OpenID Attribute Exchange (AX), для отримання інформації від провайдера.

Подібно SReg, AX використовується для організації узгодженого, стандартного процесу обміну інформацією між RP і OP. Однак на відміну від SReg, AX дозволяє обом сторонам передавати один одному інформацію будь-якого типу. Єдине, що необхідно - це підтримка AX з боку як провайдера, так і клієнта.

Якщо не вдаватися в деталі, то процес взаємодії полягає в тому, що RP запитує у OP певну інформацію, і OP пересилає її вигляді спеціального повідомлення. Повідомлення зберігаються в URL, за яким перенаправляється браузер користувача, але openid4java дозволяє працювати з їх вмістом у вигляді об'єктів.

Для виконання AX-запитів RP використовує клас FetchRequest. Отримавши посилання на повідомлення, клієнт додає до нього атрибути, значення яких повинні бути отримані від провайдера (лістинг 5).

Лістинг 5. Приклад створення екземпляра FetchRequest на стороні RP і установки значень атрибутів

AuthRequest ret = obtainSomehow (); // Створення AX-запиту для отримання улюбленого кольору користувача FetchRequest fetchRequest = FetchRequest.createFetchRequest (); fetchRequest.addAttribute ( "favoriteColor", "http://makotogroup.com/schema/1.0/favoriteColor", false); ret.addExtension (fetchRequest);

При відправці інформації назад клієнту провайдер використовує ті ж самі конструкції, як показано в лістингу 6.

Лістинг 6. Приклад відправки запитаних атрибутів клієнту

if (authRequest.hasExtension (AxMessage.OPENID_NS_AX)) {MessageExtension extensionRequestObject = authRequest.getExtension (AxMessage.OPENID_NS_AX); FetchResponse fetchResponse = null; Map <String, String> axData = new HashMap <String, String> (); if (extensionRequestObject instanceof FetchRequest) {FetchRequest axRequest = (FetchRequest) extensionRequestObject; ParameterList parameters = axRequest.getParameters (); fetchResponse = FetchResponse.createFetchResponse (axRequest, axData); if (parameters.hasParameter ( "type.favoriteColor")) {axData.put ( "favoriteColor", registrationModel.getFavoriteColor ()); fetchResponse.addAttribute ( "favoriteColor", "http://makotogroup.com/schema/1.0/favoriteColor", registrationModel.getFavoriteColor ()); } AuthResponse.addExtension (fetchResponse); } Else {// Помилка}}

Кожен з описаних атрибутів володіє ім'ям і URI. В даному випадку ім'ям атрибута є FavoriteColor, а URI - http://makotogroup.com/schema/1.0/favoriteColor.

Крім того, атрибути повинні бути Серіалізуемое в рядок (див. Приклад відправки дати в строковому поданні в вихідному коді програми). При визначенні атрибутів важливо гарантувати, що їх опис є узгодженим між провайдером і клієнтом. Інших обмежень на обмін даними не накладається.

Далі ми продовжимо розгляд етапів аутентифікації користувачів.

Аутентифікація користувача провайдером

Отже, ми зупинилися на тому, що запит на аутентифікацію надійшов на адресу кінцевої точки провайдера. У цей момент провайдер повинен проаналізувати запит і визначити подальші дії. Спочатку він визначає режим (mode) запиту, який може приймати два значення: "association" (асоціювання) і "authentication" (аутентифікація).

Лістинг 7. Обробка запиту на асоціювання провайдером

// Код узятий з конструктора класу OpenIdLoginPage public OpenIdLoginPage (PageParameters parameters) throws IOException {super (parameters); . . . if ( "associate" .equals (mode)) {OpenIdProviderService.processAssociationRequest (getResponse (), requestParameters); }. . . } // Код класу OpenIdProviderService public static void processAssociationRequest (Response response, ParameterList request) throws IOException {Message message = getServerManager (). AssociationResponse (request); sendPlainTextResponse (response, message); } Private static void sendPlainTextResponse (Response response, Message message) throws IOException {response.setContentType ( "text / plain"); OutputStream os = response.getOutputStream (); os.write (message.keyValueFormEncoding (). getBytes ()); os.close (); }

У лістингу 7 показано, як конструктор класу OpenIdLoginPage, що є точкою входу провайдера в демонстраційному додатку, аналізує запит. Якщо режим говорить про те, що надійшов запит на асоціювання, клас звертається до openid4java, яка бере на себе деталі цього процесу. При цьому звернення до бібліотеки відбувається через клас-обгортку OpenIdProviderService. Після цього запит відправляється назад на сторону клієнта.

Після того як RP переконався, що асоціювання виявилась успішною (а точніше, коли openid4java це перевірить), він виконує наступний запит до OP. Як і раніше, провайдер аналізує режим запиту. Як правило, другим надходить запит на аутентифікацію (режим "checkid_authentication").

Код конструктора класу OpenIdLoginPage приведений в лістингу 8.

Лістинг 8. Розбір запиту з режимом checkid_authentication за допомогою openid4java

public OpenIdLoginPage (PageParameters parameters) throws IOException {super (parameters); . . . else if ( "checkid_immediate" .equals (mode) || "checkid_setup" .equals (mode) || "check_authentication" .equals (mode)) {if (((MakotoOpenIdAwareSession) getSession ()). isLoggedIn ()) {/ / Створення об'єкта AuthResponse на основі даних в сесії sendSuccessfulResponse (); } Add (new OpenIdLoginForm ( "form")); . . }

Знову зверніть увагу на виділені рядки. У першій з них клас OpenIdLoginPage повертає позитивну відповідь на запит. Спочатку він за допомогою класу Session перевіряє, чи виконав користувач вхід в додаток раніше (в цьому випадку аутентифікація не вимагається). Якщо так, то клієнту повертається відповідь з ознакою успішної аутентифікації. Саме так працює механізм аутентифікації в демонстраційному додатку.

Якщо ж користувач раніше не входив в систему, то Wicket створює форму аутентифікації, на якій слід ввести параметри облікового запису (малюнок 2).

Малюнок 2. Сторінка провайдера з формою входу для нерозпізнаних користувачів

Якщо користувач успішно пройшов аутентифікацію, провайдер відправляє клієнту відповідь, що включає додаткову інформацію, а саме - об'єкт DiscoveryInformation, який потім зберігається в сесії. Всі ці дії є частинами механізму єдиної аутентифікації.

У цей момент браузер користувача перенаправляється назад на сторінку RP (URL заданий в параметрі "return-to"), отримуючи повідомлення про успішну аутентифікації.

надання доступу

Отримавши від провайдера повідомлення AuthResponse з ознакою успішної аутентифікації, RP повинен вирішити, чи слід надати користувачеві доступ до ресурсу. Демонстраційне додаток автоматично відкриває доступ для всіх користувачів, аутентіфіцированний провайдером. Крім того, RP отримує від провайдера запитану інформацію про користувача, яка потім відображається на сторінці реєстрації, як показано на малюнку 3.

Малюнок 3. Сторінка реєстрації, що відображає інформацію про користувача, отриману від провайдера

Висновок

Прочитавши цю статтю, ви дізналися про застосування OpenID при реалізації механізму єдиної аутентифікації користувачів для кластера з декількох додатків. Дана архітектура має на увазі, що між додатками встановлені довірчі відносини, а один з додатків виконує функції провайдера OpenID (OP).

Застосування OpenID для аутентифікації і обміну даними гарантує, що взаємодіючі сторони використовують єдиний, узгоджений підхід до аутентифікації і авторизації. В даний час OpenID є широко поширеним стандартом, тому починаючи його використовувати, ви можете розраховувати на потужну підтримку спільноти в тому, що стосується навчання, а також діагностики проблем, пов'язаних з реалізаціями специфікації.

Якщо вас цікавлять подробиці механізму єдиної аутентифікації, реалізованого в цій статті, зверніться до вихідного коду демонстраційного додатки. Зберіть код програми у вигляді WAR-архіву, скопіюйте в директорію Tomcat і запустіть сервер. При цьому не забудьте включити режим журналювання TRACE, оскільки виводяться в журнал повідомлення розкажуть вам про деталі реалізації, які не обговорювалися в цій статті.

Подібно будь-якої специфікації, "Аутентифікація OpenID" досить складна, але бібліотека openid4java істотно полегшує її використання. Ви можете вільно завантажуваті вихідний код до цієї статті і використовувати його при реалізації механізму аутентифікації в ваших додатках.

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів

Jsp?
Навіщо потрібно розширення AX?

Nav view search

Навигация

Курсы

бесплатные приколы

шаблоны joomla 1.7

Дополнительная информация

Новости

Учебный центр "Магнат"...

Дизаин интерьера и...

web-дизайн

Практическая...

Курсы массажа