Начнем с представления более строгого определения
"Механизм, с помощью которого единственное действие по аутентификации и авторизации пользователя может разрешить ему доступ ко всем компьютерам и системам, к которым этот пользователь имеет разрешение на доступ, без необходимости ввода множества паролей".
Это определение взято с Web-сайта компании The
Ключевым моментом здесь является то, что пользователю требуется войти в систему (пройти аутентификацию) для подключения к приложению только один раз, причем в контексте этой же сессии нет необходимости проходить аутентификацию повторно при доступе к другому приложению или серверу.
Этот подход предполагает появление определенного количества важных преимуществ, но имеет также и некоторые недостатки. Преимуществами для конечных пользователей являются следующие положения:
Преимущества для
Потенциальные недостатки
Сложность обеспечения credentials ), которые могут понять и правильно обработать ( accept ) все приложения. Также нам нужно иметь возможность проверить достоверность параметров доступа пользователя ( credentials )
C технической точки зрения существует несколько различных методов, или инструментов, которые могут быть использованы, чтобы обеспечить пользователям возможность использования
Все методы
В этом разделе мы обсудим четыре основных метода, используемых для поддержки
Обратите внимание на то, что мы проводим различие между понятием credentials )], хранящихся во множестве мест для использования различными приложениями. При таком сценарии у пользователей запрашивалась бы аутентификация для каждого приложения (или сервера), к которым они осуществляют доступ, несмотря на то, что теоретически они бы использовали для этого одни и те же ID и пароль.
Чтобы иметь единый пароль несмотря на то, что каждое приложение использует специализированное хранилище для ID и пароля ( credentials store ), идентификаторы ( ID ) пользователей и пароли должны быть каким-то образом синхронизированы. Так как же можно синхронизировать пароли в различных хранилищах (каталогах)? Самый простой ответ, это пользователи могут вручную поддерживать идентичность своих logon-имен и паролей для различных систем, если у них есть на это соответствующие полномочия. Конечно, это без сомнения, самый недружелюбный к пользователю подход, потому что нагрузка в этом случае полностью ложится на него. Могут ли пароли быть синхронизированы программно? В некоторых случаях могут, хотя на самом деле процесс синхронизации представляет из себя одновременную смену паролей.
Большинство процессов "синхронизации" паролей технически являются процессом одновременного изменения паролей, происходящим в фоновом режиме. К примеру, если вы разрешили синхронизацию паролей Notes и Windows, то при изменении вами своего пароля в Notes введенный новый пароль временно сохраняется в буфере, после чего автоматически передается процессу изменения пароля Windows в фоновом режиме. Процесс очень похож на процесс синхронизации пароля Notes и Domino интернет-паролей. Одновременное изменение эффективно там, где вам необходимо набрать пароль только один раз, и он автоматически будет передан второй парольной системе.
С точки зрения обеспечения безопасности, возможность синхронизации значения пароля из хранилища, непременно связано с возникновением очень нежелательных слабых мест в системе безопасности. Слабым местом в этом случае была бы возможность извлечения версии пароля пользователя в виде открытого текста для того, чтобы его можно было записать в другой каталог. Безопасные хранилища входных данных не хранят пароль в виде открытого текста, скорее они хранят хеш или зашифрованную версию пароля. Алгоритм хеширования не должен быть реверсивным. Так, чтобы у нас не было возможности прочитать из каталога значение хеша и конвертировать его в текст. А если мы просто перепишем хешированый пароль из одного каталога в другой, то второй каталог будет иметь "хеш"-значение пароля, которое не сможет быть воспроизведено в исходный пароль, и поэтому никогда не пройдет процесс аутентификации или "связывания" ( "bind" ).
Примечание. Domino генерирует salted хеш). Значение(величина) хеш не подразумевает переносимости
Если каталог предусматривает доступ администратора или программы для получения пароля в виде открытого текста, это не является безопасным.
Для понимания проблемы паролей и факта хранения хешированного значения пароля в "безопасных" каталогах, вам необходимо понять процесс аутентификации. Когда пользователь предоставляет регистрационное имя ( ID ) и пароль, строка пароля хешируется и затем сравнивается с значением хеша сохраненного в каталоге. Хорошим примером этого процесса является bind -запрос протокола LDAP, при использовании LDAP для хранения ID и пароля ( credentials ). Если полученный после ввода имени и пароля пользователя хеш соответствует хеш, сохраненному в каталоге, считается что "связывание" ( "bind" ) прошло успешно. Несмотря на то, что некоторые каталоги хранят как исходный пароль, так и его хеш-значение, безопасные каталоги не подразумевают доступ к исходному паролю; вы можете получить доступ только к хеш.
Рассмотрим следующий пример.
Пароль пользователя состоит из строки символов "password" и сохранен в IBM "[B@7a8ea817". Что случится, если мы попытаемся синхронизировать это хеш-значение с документом Person пользователя в каталоге Domino? Хеш-значение, которое сгенерирует наш сервер Domino когда мы войдем (log in) ( bind ) с паролем "password", будет выглядеть как "355E98E7C7B59BD810ED845AD0FD2FC4". Так как это значение не идентично хеш-значению из каталога LDAP, с которым мы синхронизировались ( "[B@7a8ea817" ), аутентификация с Domino будет неудачной.
Применение единого пароля и синхронизации паролей является подходом, который минимально пригоден для, возможно, двух различных клиентов, таких как пароли Notes и Windows. Это не тот подход, который мы рекомендуем для интеграции браузерных приложений. В оставшейся части этой лекции внимание будет сфокусировано на принципе единого входа (
Маркеры Lightweight Third
Маркер LTPA содержит данные, которые уникально идентифицируют пользователя, такие, как
Особые примечания относительно использования LTPA включают:
Условие относительно того, что все серверы приложений должны находиться в одном и том же домене DNS, не является ограничением, предъявляемым только LTPA. Маркер LTPA является cookie сеанса браузера, а свойства таких cookies определены в RFC-2965, который доступен по адресу:
http://www.ietf.org/rfc/rfc2965.txt
Этот RFC устанавливает, что агент пользователя (браузер) не предоставит cookie серверу, находящемуся в домене DNS, отличном от того, в котором находится выпустивший (установивший) cookie хост (сервер). Существуют прокси-архитектуры, которые могут распространяться за пределы отдельного домена DNS, но рассмотрение подобных развитых архитектур выходит за рамки данного курса.
Для преодоления проблемы наличия множества доменов DNS существуют некоторые обходные маневры. Важным для понимания понятием является то, что домен или некая область из cookie сеанса LTPA используется только браузером клиента, но не серверами приложений. Таким образом, ключом для решения этой проблемы является использование псевдонимов DNS способом, при котором браузер отправляет cookie всем серверам, вовлеченным в доверенную среду LTPA, даже если реально они находятся в других доменах. К примеру, если ваши серверы Domino находятся в домене alpha.com, а вы имеете сервер портала в домене beta.com со страницей, на которой пользователи могут получать свою почту iNotes посредством iframe, то в Domino R5 вам необходимо сконфигурировать виртуальные серверы таким образом, чтобы они работали так, как если бы находились в домене beta.com. В Domino 6 для beta.com используйте документы Internet Site. В любом случае вам необходимо убедиться в том, что для серверов Domino в домене beta.com существуют записи псевдонимов DNS.
Для обеспечения поддержки принципа единого входа между протоколами, такими, как HTTP и DIIOP (а также с сервером приложений IBM WebSphere), Domino предусматривает криптографический механизм на основе маркеров. Серверы, которые участвуют в обеспечении принципа единого входа, применяют зашифрованную "Web-конфигурацию "Web ) для совместного использования секретных данных в каталоге Domino в целях генерирования и проверки достоверности маркеров единого входа. Эта секретная информация используется сервером для проверки того, что представленный пользователем маркер был сгенерирован сервером, который совместно использует тот же секрет. В оставшейся части этой лекции мы ограничимся рассмотрением маркеров LTPA в WebSphere.
WebSphere использует формат, называемый Lightweight Third
Примечание. В среде, где WebSphere используется совместно с продуктами Lotus, или Tivoli, или обоими вместе, ключи LTPA должны генерироваться WebSphere и импортироваться в другие продукты. Когда взаимодействие с WebSphere не требуется, Domino использует для маркера единого входа свой собственный формат, который незначительно отличается от реализованного в WebSphere. Серверы, участвующие в Domino
При применении LTPA в качестве механизма аутентификации для аутентификации пользователя применяется доверенный сторонний сервер. В зависимости от того, выпущен ли уже для пользователя маркер, Web-сервер может выполнить одно из двух возможных действий. Этими двумя действиями, или механизмами, являются:
Пользователи подвергаются аутентификации один раз за время сеанса. Первоначальная аутентификация с использованием LTPA основана на имени и пароле, хранящихся в каталоге LDAP, когда каталогу доверяют все приложения, которые совместно используют cookie сеанса LTPA. Обратите внимание на то, что ID ) и пароль первоначальному серверу в среде LTPA, тот предоставляет этот
| Данные | Значение |
|---|---|
CookieName (Имя cookie) |
"LtpaToken" (Маркер LTPA) |
CookieValue (Значение cookie) |
Закодировано Base64 (Маркер LTPA) |
LtpaToken (Маркер LTPA) |
Зашифровано (Маркер аутентификации, совместно используемый ключ) с использованием 3DES |
AuthenticationToken (Маркер аутентификации) |
Данные пользователя+"%"+Дата истечения срока действия маркера+"%"+Закодировано Base64 (Цифровая подпись) |
|
Подписано (Данные пользователя, дата истечения срока действия маркера) с использованием секретного ключа LTPA (с применением RSA/SHA1) |
PrivateKey-ltpa (Секретный ключ LTPA) |
Секретный ключ (соответствующий открытому ключу, к которому могут получить доступ другие серверы) используется сервером LTPA для подписи данных аутентификации; этот секретный ключ должен быть доступен только серверу LTPA |
SharedKey (Совместно используемый ключ) |
Симметричный/совместно используемый ключ 3DES, который совместно применяется сервером LTPA и другими серверами для шифрования/расшифровки маркера |
UserData (Данные пользователя) |
Пары имени и значения, отделенные разделителем "$" (к примеру, "uid:"+ID пользователя) |
TokenExpirationDate (Дата истечения срока действия маркера) |
Число, представляющее время и дату истечения срока действия маркера. (Дата истечения срока действия маркера является числом миллисекунд, которые проходят начиная с полночи (00:00:00) 1 января 1970 г.) |
Обратите внимание на то, что внутри закодированной структуры находится цифровая подпись. Эта подпись сделана выпустившим маркер сервером с использованием секретного ключа сервера (в случае сервера Domino) или ключа, сгенерированного псевдослучайным образом (в случае сервера WebSphere).
Если пользователь уже имеет маркер LTPA, то затем маркер подвергается проверке достоверности со стороны получившего его Web-сервера. Web-сервер, в свою очередь, может запросить для проверки достоверности удостоверения личности (
Следующий пример отображает журнал отладки сервера Domino, выполняющего три шага по обработке полученного им маркера LTPA, сгенерированного WebSphere: декодирование кода Base64, расшифровка с применением совместно используемого секретного ключа (импортированного из WebSphere), и определение того, следует ли доверять имени пользователя в маркере как пользователю, прошедшему аутентификацию.
06/09/2003 05:53:39.53 PM [03071:00010-106510] SSO API> Decoding Websphere
style Single Sign-On token (LTPA).
06/09/2003 05:53:39.53 PM [03071:00010-106510] SSO API> Dumping memory
of encoded token [364 bytes].
00000000: 6C71 3150 4847 4536 3576 597A 6154 7878 'qlP1GH6Ev5zYTaxx'
00000010: 6F5A 534D 4262 6D70 3746 4643 6B56 3172 'ZoMSbBpmF7CFVkr1'
00000020: 5146 7045 5762 756E 6467 4532 6C68 314B 'FQEpbWnugd2EhlK1'
00000030: 3138 6E47 5164 5A41 634C 3965 3258 386C '81GndQAZLce9X2l8'
00000040: 2B7A 7239 7263 7976 5537 6332 4957 4F44 'z+9rcrvy7U2cWIDO'
00000050: 3755 4677 586D 2B6B 3768 7A31 3767 6976 'U7wFmXk+h71zg7vi'
00000060: 3672 5949 4672 7566 4C4D 636E 6236 665A 'r6IYrFfuMLnc6bZf'
00000070: 6E63 6A43 6246 4476 7159 476A 2F72 5445 'cnCjFbvDYqjGr/ET'
00000080: 6742 6C57 7779 7457 3671 6632 7467 3978 'BgWlywWtq62fgtx9'
00000090: 4947 6D71 4674 6643 7470 716D 6E56 5863 'GIqmtFCfptmqVncX'
000000A0: 6C43 5A4A 5050 4E48 4733 336E 6F69 757A 'ClJZPPHN3Gn3iozu'
000000B0: 4562 3777 475A 6136 3362 5138 6C4D 7554 'bEw7ZG6ab38QMlTu'
000000C0: 5475 7166 7438 5971 5269 5736 4949 6238 'uTfq8tqYiR6WII8b'
000000D0: 5839 6578 6552 714F 6378 6A35 4663 6435 '9XxeReOqxc5jcF5d'
000000E0: 4343 4E69 3076 4A6D 4372 686A 306C 6A51 'CCiNv0mJrCjhl0Qj'
000000F0: 4F57 6142 5955 7634 7771 3838 5A57 3230 'WOBaUY4vqw88WZ02'
00000100: 6F42 7671 3939 7231 5765 3068 4753 596B 'Boqv991reWh0SGkY'
00000110: 7A63 5862 4D31 4A4B 314E 4F6B 3576 4337 'czbX1MKJN1kOv57C'
00000120: 7449 654A 5253 3577 477A 4352 384D 684C 'ItJeSRw5zGRCM8Lh'
00000130: 6665 4E43 7365 504C 6B2B 7258 5157 7343 'efCNesLP+kXrWQCs'
00000140: 5866 3741 576C 534C 4630 6941 3035 6C76 'fXA7lWLS0FAi50vl'
00000150: 3247 356E 5076 2B68 4968 2F64 6955 3442 'G2n5vPh+hId/UiB4'
00000160: 5065 4F6F 324C 476D 3958 3D30 'ePoOL2mGX90='
06/09/2003 05:53:39.55 PM [03071:00010-106510] SSO API> Dumping memory
of encoded token before decryption step [272 bytes].
00000000: 53AA 18F5 847E 9CBF 4DD8 71AC 8366 6C12 '*Su.~.?.XM,qf..l'
00000010: 661A B017 5685 F54A 0115 6D29 EE69 DD81 '.f.0.VJu..)min.]'
00000020: 8684 B552 51F3 75A7 1900 C72D 5FBD 7C69 '..R5sQ'u..-G=_i|'
00000030: EFCF 726B F2BB 4DED 589C CE80 BC53 9905 'Ookr;rmM.X.NS<..'
00000040: 3E79 BD87 8373 E2BB A2AF AC18 EE57 B930 'y>.=s.;b/".,Wn09'
00000050: E9DC 5FB6 7072 15A3 C3BB A862 AFC6 13F1 '\i6_rp#.;Cb(F/q.'
00000060: 0506 CBA5 AD05 ADAB 829F 7DDC 8A18 B4A6 '..%K.-+-..\}..4'
00000070: 9F50 D9A6 56AA 1777 520A 3C59 CDF1 69DC 'P.Y*Vw..RY<qM\i'
00000080: 8AF7 EE8C 4C6C 643B 9A6E 7F6F 3210 EE54 'w..nlL;dn.o..2Tn'
00000090: 37B9 F2EA 98DA 1E89 2096 1B8F 7CF5 455E '97jrZ.... ..u|^E'
000000A0: AAE3 CEC5 7063 5D5E 2808 BF8D 8949 28AC 'c*ENcp^].(.?I.,('
000000B0: 97E1 2344 E058 515A 2F8E 0FAB 593C 369D 'a.D#X`ZQ./+.<Y.6'
000000C0: 8A06 F7AF 6BDD 6879 4874 1869 3673 D4D7 '../w]kyhtHi.s6WT'
000000D0: 89C2 5937 BF0E C29E D222 495E 391C 64CC 'B.7Y.?.B"R^I.9Ld'
000000E0: 3342 E1C2 F079 7A8D CFC2 45FA 59EB AC00 'B3Bayp.zBOzEkY.,'
000000F0: 707D 953B D262 50D0 E722 E54B 691B BCF9 '}p;.bRPP"gKe.iy<'
00000100: 7EF8 8784 527F 7820 FA78 2F0E 8669 DD5F 'x~...R xxz./i._]'
06/09/2003 05:53:39.55 PM [03071:00010-106510] SSO API> Dumping memory
of encoded token after decryption step [271 bytes].
00000000: 3A75 7375 7265 3A5C 7469 6F73 6573 2D63 'u:user\:itsosec-'
00000010: 646C 7061 632E 6D61 692E 7374 2E6F 6269 'ldap.cam.itso.ib'
00000020: 2E6D 6F63 5C6D 333A 3938 552F 4449 443D 'm.com\:389/UID=D'
00000030: 6948 6B6E 656C 4F2C 3D55 7250 646F 6375 'Hinkle,OU=Produc'
00000040: 6974 6E6F 6F2C 723D 6465 6F62 6B6F 2C73 'tion,o=redbooks,'
00000050: 3D63 7375 3125 3530 3235 3831 3733 3138 'c=us%10552183781'
00000060: 3635 4125 4274 4669 5238 3748 4858 6C4F '56%AtBiF8RH7XHOl'
00000070: 7A47 554F 5645 3575 7456 4172 597A 765A 'GzOUEVu5VtrAzYZv'
00000080: 6756 314E 5374 6548 3671 7573 554E 6872 'VgN1tSHeq6suNUrh'
00000090: 4E4B 3537 6632 6442 6A35 3161 6969 3479 'KN752fBd5ja1iiy4'
000000A0: 2F65 5868 7261 5A7A 4D6A 5977 6E6F 715A 'e/hXarzZjMwYonZq'
000000B0: 7868 2B43 4142 7434 7A52 5764 4B33 4E6A 'hxC+BA4tRzdW3KjN'
000000C0: 3044 6471 4B55 4C48 7450 5772 7150 2B48 'D0qdUKHLPtrWPqH+'
000000D0: 4655 7A33 4469 4F75 3261 4B4A 7349 5855 'UF3ziDuOa2JKIsUX'
000000E0: 6A69 684A 5567 594D 4335 6266 3335 3256 'ijJhgUMY5Cfb53V2'
000000F0: 6263 7034 4657 6851 6A35 7152 7636 3641 'cb4pWFQh5jRq6vA6'
00000100: 6339 4662 4441 5A58 7248 744D 414A 3D '9cbFADXZHrMtJA='
06/09/2003 05:53:39.56 PM [03071:00010-106510] SSO API> -LDAP Realm
= itsosec-ldap.cam.itso.ibm.com\:389
06/09/2003 05:53:39.56 PM [03071:00010-106510] SSO API> -Username
= UID=DHinkle/OU=Production/o=redbooks/c=us
06/09/2003 05:53:39.56 PM [03071:00010-106510] SSO API> -Expiration
Ticks = 1055218378666 [06/10/2003 12:12:58 AM].
06/09/2003 05:53:39.56 PM [03071:00010-106510] WebAuth> LOOKUP in view
$Users (user='UID=DHinkle/OU=Production/o=redbooks/c=us')
В этом примере обратите внимание на то, что Domino не осуществляет проверку достоверности цифровой подписи выпустившего сервера, когда определяет, что это маркер LTPA WebSphere. Domino интересует только три аспекта относительно принятого маркера LTPA:
Как правило, серверы WebSphere не имеют доступных Domino открытых/секретных ключей и, значит, без наличия общей инфраструктуры открытых ключей (PKI) для Domino не существует способа проверить достоверность цифровой подписи сервера WebSphere.
Основным соображением относительно обеспечения безопасности при использовании LTPA в смешанной среде WebSphere-Domino является защита совместно используемого секретного ключа. Если секретный ключ был скомпрометирован, то для осведомленного относительно этого факта лица становится возможным генерировать поддельные маркеры. Несмотря на всевозможные меры относительно защиты секретного ключа, теоретически он все еще уязвим для автономных атак в том случае, если достаточное количество маркеров получено посредством выборки (с помощью сетевого сниффинга) и кто-то может определить ключ с применением взлома по методу "грубой силы" (brute force
Управление доступом с использованием LTPA основано на содержащемся внутри маркера имени пользователя. Это имя будет отличительным именем [distinguished name (DN)] из каталога LDAP, применяемым в мандате пользователя. Если DN в маркере не соответствует элементу управления доступом [к примеру, элементу
Domino 6, а именно 6.0.2 и выше, обеспечивает чрезвычайно полезные возможности, которые позволяют устанавливать соответствие между содержащимся в маркере LTPA отличительным именем (DN) и другим именем в интересах управления доступом (осуществлять их преобразование). Сам по себе маркер LTPA не изменяется (не генерируется повторно), но аутентифицированное имя пользователя преобразовывается из отличительного имени LDAP в другое
Дополнительная информация о функциях преобразования различных имен в Domino описана в разделе 11.9.4, "Преобразование имен в Domino".
В дополнение к возможностям преобразования имен в Domino Tivoli WebSeal в связке с Tivoli
Если при конфигурировании инфраструктуры LTPA возникают проблемы, должны быть тщательно проанализированы значения различных параметров, связанных с LDAP. При использовании Lotus-технологий неправильная установка параметров "search filters" и "base dn" является причиной не менее 75 % связанных с LDAP-аутентификацией проблем.
Фактически для изменения связанных с аутентификацией фильтров поиска (search filters) существует множество мест, и все из них должны быть проверены тщательным образом:
Пример фильтра поиска Sametime показан на рис. 7.1.
(рис 7.1) Фильтр поиска LDAP SametimeЕсли после того, как вы исследовали соответствующие параметры LDAP, связанные с LTPA проблемы все еще случаются, то далее надо внимательно изучить файлы отладки и трассировки.
В NOTES.INI существует отладочная переменная, которая доступна в целях содействия в отыскании проблем с шифрованием и расшифровкой маркеров единственной подписи (DEBUG_SSO_TRACE_LEVEL=1. Для получения подробных дампов памяти, содержащих информацию о том, как шифруются и расшифровываются маркеры, установите DEBUG_ SSO_TRACE_LEVEL=2.
Примечание. Domino 6 может иметь различные конфигурации
Аутентификация клиента с использованием сертификатов X.509 предусматривает
Как правило, сертификат X.509 клиента защищен паролем, поэтому в данном случае использование сертификатов X.509 рассматривается как двухфакторный метод аутентификации: что-то у вас есть (сертификат на рабочей станции), а что-то вы знаете (пароль). Так как сертификаты могут также быть проверены, проконтролированы на предмет аннулирования и истечения срока действия, то сертификаты X.509 могут быть очень безопасным методом аутентификации пользователей. Однако в связи с тем, что сертификат X.509 сделан переносимым (или экспортируемым) и он может быть установлен в другие приложения или на другие рабочие станции, появляются как проблемы логистики для пользователя, так и потенциальные уязвимости в безопасности. Достоин упоминания тот факт, что Internet Explorer хранит сертификаты X.509 клиента в реестре Windows. Полное удаление сертификата с рабочей станции может потребовать ручного удаления его из реестра. Только недавно получили толчок в своем развитии смарт-карты как средства, обеспечивающие как переносимость, так и безопасность в хранении сертификатов клиента, причем несмотря на то, что недостаток, связанный с отсутствием повсеместного использования устройств считывания смарт-карт в персональных компьютерах, определенно затрудняет их широкое использование.
При аутентификации клиента клиент LDAP, а именно браузер, установленный на рабочей станции клиента, должен иметь цифровой сертификат (на основе стандарта X.509). Другими словами, сертификат X.509 содержит
В дополнение к SSL-аутентификации клиентов Web-браузеров для добавления к протоколам на основе соединений поддержки аутентификации на базе сертификатов X.509 может использоваться протокол SASL (Simple Authentication and Security Layer). Данный протокол содержит команду для идентификации и аутентификации пользователя по отношению к серверу. По выбору он может согласовывать уровень безопасности для последующего взаимодействия в рамках протокола. Если более точно, то существует как минимум семь различных типов поддерживаемой SASL аутентификации, но лишь тип аутентификации SASL "External" (Внешняя) использует сертификаты X.509. Спецификации SASL описаны в RFC-2222, который можно найти на адресу:
http://www.ietf.org/rfc/rfc2222.txt
Описание аутентификации и управления доступом в последующих двух разделах имеют отношение к процессу, используемому каталогом LDAP для аутентификации клиента. Это высокоуровневый обзор процесса при использовании каталога LDAP, причем описание поддержки X.509 в любом предоставленном продукте компании Lotus не обязательно.
После того как сервер получает команду аутентификации или любой ответ клиента, он может либо выдать вызов, либо отобразить ошибку или завершение. Если клиент получает вызов, он может выдать ответ либо прервать обмен в зависимости от профиля протокола.
Сейчас мы опишем последовательность аутентификации, которая выполняется с применением для аутентификации по протоколу SASL сертификатов X.509v3. Во время протокольного обмена в рамках аутентификации механизм SASL выполняет аутентификацию, передавая личность авторизации [известную как идентификатор пользователя (userid)] от клиента к серверу и договариваясь об использовании определенного механизмом уровня безопасности.
Когда сервер LDAP получает от клиента запрос связывания LDAP, он обрабатывает запрос следующим образом:
=EXTERNAL ) и тип аутентификации SSL является аутентификацией сервера и клиента, то сервер подтверждает, что сертификат клиента является действительным, был выпущен известным CA и в цепочке сертификатов клиента не существует недействительных или ldap_sasl_bind, не имеют значения NULL, то затем для последующих операций LDAP в качестве аутентифицированной личности используется NULL и LDAP_AUTH_NONE соответственно.Использование сертификатов клиента X.509 для
SASL поддерживает такое свойство, как прокси-авторизация (proxy authorization), которое позволяет аутентифицированным пользователям осуществлять запрос выполнения ими действий от лица другого пользователя. Этот шаг происходит после того, как пользователь получает
Интерфейс прикладного программирования Web-сервера Domino [Domino Web
Обратите внимание на то, что некоторые бизнес-партнеры IBM Lotus предлагают как стандартные, так и пользовательские решения для Web-аутентификации пользователей с применением DSAPI на основе инструментария интерфейса прикладного программирования на языке С Domino 6. За дополнительной информацией обратитесь к Web-сайту компании IBM.
Фильтр DSAPI позволяет вам настраивать обработку HTTP-запроса при возникновении определенных событий, например когда пользователь осуществляет доступ к ресурсу на сервере первый раз и вы желаете использовать специальную обработку данных аутентификации вместо обычной Web-аутентификации Domino. Процесс применяет набор предопределенных типов событий. Стек HTTP уведомляет фильтр DSAPI o событиях, после чего определенная разработчиком DSAPI логика принимает решение о том, что делать по факту наступления события. В настоящее время после события StartRequest существует 13 событий, которые могут быть перехвачены фильтром DSAPI. В зависимости от конструкции и ее реализации фильтр может поддерживать либо одно событие, либо некоторое их количество.
Реализация интерфейса DSAPI зависит от того, индикацию ("регистрацию") каких из событий фильтр поддерживает. Итак, фильтр получает от менеджера соединений стека уведомления только о тех событиях, о поддержке которых он заявил. Рис. 7.2 отображает, где фильтр DSAPI вступает в действие на HTTP-сервере Domino относительно другой обработки данных на Web-сервере.
(рис 7.2) Технологический процесс обработки стека интернет-протокола Domino 6В общем, события происходят в определенной последовательности. Они отражаются на состоянии стека HTTP на каждом из его шагов по обработке данных. Filter Init Data, когда фильтр загружен и проинициализирован). Типами методов запроса HTTP, при которых могут быть инициированы события, являются:
HEAD: метод HEAD часто используется для тестирования гипертекстовых ссылок в целях проверки достоверности, доступности и недавней модификации.GET: метод GET используется для выполнения выборки любой информации (в форме объекта), идентифицированной посредством Request-URL (URL-запроса).POST: метод POST требует, чтобы исходный сервер принимал объект, содержащийся в запросе, как новую субординантную информацию для ресурса, который идентифицирован посредством Request-URL в Requst-Line (Строка-статус).PUT: метод PUT требует, чтобы содержащийся в запросе элемент был сохранен по представленному Request-URL.DELETE: метод DELETE требует, чтобы исходный сервер удалил ресурс, идентифицированный посредством Request-URL.TRACE: метод TRACE.CONNECT: метод CONNECT.OPTIONS: метод OPTIONS.UNKNOWN: неизвестный метод запроса.BAD: неверный метод запроса. Ошибка.Типы событий описаны в последующих разделах в порядке их возникновения.
Это событие используется для того, чтобы информировать все загруженные в текущий момент фильтры о том, что запрос HTTP был принят и вскоре будет обрабатываться. На этом шаге фильтр может подготовиться к обработке запроса. Как правило, на этом шаге фильтр должен распределить свои собственные данные секретного контекста и требуемые ресурсы, необходимые для управления обработкой запроса. Параметр pEventData не используется, передается NULL. Любой фильтр, поддерживающий это событие, должен возвращать значение kFilterHandledEvent.
Все фильтры, загруженные на данный момент и поддерживающие это событие, уведомляются о том, что были изучены все входящие заголовки HTTP. Любой фильтр, которому необходима предварительная обработка входящих заголовков, может сделать это в данный момент времени. Обратите внимание на то, что в данный момент времени фильтр мог бы выбрать полное обслуживание запроса HTTP. Параметр pEventData является указателем на структуру FilterRawRequest.
Все фильтры, загруженные на данный момент и поддерживающие это событие, уведомляются о нем, когда стек HTTP заканчивает предварительный анализ всех входящих заголовков HTTP. Обратите внимание на то, что это отражает состояние, аналогичное состоянию в событии kFilterRawRequest, так как стек HTTP предварительно анализирует входящие заголовки HTTP перед тем, как начнет вызывать какой-либо фильтр. На этом шаге для полной обработки запроса вновь может быть выбран любой фильтр. Параметр pEventData является указателем на структуру FilterParsedRequest. Обратите внимание на то, что предусмотрены только две kFilterRawRequest.
Все фильтры, загруженные на данный момент и поддерживающие это событие, имеют возможность изменить URL-адрес для перенаправления запроса на некий другой ресурс. Если фильтр успешно переписывает URL-адрес для обработки и сервер обрабатывает этот новый URL-адрес, то после этого на уровне DSAPI обработка данного события заканчивается, а это означает, что другие фильтры в списке не будут уведомляться. Параметр pEventData является указателем на экземпляр структуры FilterMapURL. Обратите внимание на тот факт, что FilterMapURL используется также в таких событиях, как kFilterTranslateRequest и kFilterPostTranslate.
Это событие происходит, когда стек HTTP находится в фазе аутентификации процесса. Код фильтра способен осуществить просмотр запроса и pEventData является указателем на экземпляр структуры.
Это событие происходит, когда стек HTTP близок к генерированию списка имен групп пользователя. Это имена групп, членами которых является пользователь. Данное событие следует за событием kFilterAuthenticate. Этот фильтр может либо устанавливать, что сервер Domino заполняет список, добавляет или удаляет группы из списка, либо полностью обрабатывать событие (полностью самостоятельно генерировать список групп). Параметр pEventData в функции HttpEventProc является указателем на структуру FilterUserNameList.
Это событие происходит, когда стек HTTP близок к преобразованию URL-адреса пути в целевой ресурс. Фильтр может либо преобразовывать запрос с использованием своих собственных правил преобразования и построения соответствий, либо полностью обрабатывать запрос. Параметр pEventData является указателем на экземпляр структуры FilterMapURL.
Это событие происходит после того, как было обработано событие kFilterTranslateEvent. Для фильтра это возможность изменить целевой ресурс, к которому осуществляется доступ. Фильтр может изменять как путь целевого ресурса, так и тип построения соответствий. Фильтр может также выбрать полное обслуживание запроса. Параметр pEventData является указателем на экземпляр структуры FilterMapURL.
Это событие происходит после того, как имела место фаза аутентификации и был вычислен список имен групп пользователя. Фильтр может отвергнуть реализацию фазы авторизации по умолчанию и либо предоставить доступ к целевому ресурсу либо отказать в нем. Параметр pEventData является указателем на структуру FilterAuthorize. Она содержит информацию об используемом целевом ресурсе. Обратите внимание на тот факт, что фильтр может получить доступ к информации аутентифицированного пользователя путем применения служб при помощи ServerSupport с установленным флагом kGetAuthenticatedUserInfo. Это даст возможность пользователю получить доступ к аутентифицированному имени пользователя, а также к его или ее списку имен групп.
Если фильтр отказывает в доступе к целевому ресурсу, он должен отправить клиенту соответствующий ответ и установить поле isAuthorized структуры FilterAuthorize в значение 0. После этого он может вернуть либо kFilterHandledRequest, либо kFilter-HandledEvent. После этого на уровне DSAPI стеку HTTP будет подан сигнал на завершение обработки текущего запроса.
Это последний шаг в обслуживании запроса HTTP. Это событие может быть использовано для отклонения реализации обработки запроса по умолчанию. На этой стадии данные для ответа вычисляются и отправляются клиенту. Параметр pEventData является указателем на структуру FilterMapURL.
Это событие используется для информирования кода фильтра о том, что наступило время для обновления и освобождения ресурсов, выделенных для обработки заданного запроса HTTP. Параметр pEventData в этом случае имеет значение NULL.
Это событие заменено событием kFilterAuthenticate, но все еще поддерживается для обеспечения совместимости с написанными ранее фильтрами DSAPI. При этом событии фильтр осуществляет аутентификацию Web-пользователя. Параметр pEventData является экземпляром структуры FilterAuthenticate. Использование приведено в описанном ранее событии kFilterAuthenticate.
Это событие позволяет вам осуществлять настройку аутентификации Web-пользователей, которая зачастую является единственной частью реализации принципа единого входа в корпорации. В этом случае фильтр DSAPI уведомляется, когда Domino осуществляет аутентификацию пользователя. После этого фильтр DSAPI может проанализировать имя пользователя, проверить достоверность имен пользователей и паролей по отношению к действующей основной системе и, если проверка прошла успешно, уведомить Web-сервер Domino, что он обрабатывал аутентификацию пользователя, а также вернуть Domino
Далее приведено руководство по настройке выходных переменных и кодов возврата для общих сценариев аутентификации, когда eventData указывает на структуру FilterAuthenticate.
Сценарий 1. Фильтр был способен провести аутентификацию пользователя.
Установите eventData > authName в каноническое имя, установите eventData > authType в kAuthenticBasic или kAuthenticClientCert, а код возврата в kFilterHandledEvent.
Сценарий 2. Фильтр был неспособен провести аутентификацию пользователя, а другие фильтры или Domino должны двигаться вперед и предпринимать попытки проведения своей собственной аутентификации.
Установите код возврата в kFilterNotHandled.
Сценарий 3. Фильтр был неспособен провести аутентификацию пользователя, а другие фильтры или Domino не должны предпринимать попытки проведения своей собственной аутентификации.
Установите eventData > authType в kNotAuthentic, а код возврата в kFilterHandledEvent.
Это событие происходит, когда стек HTTP близок к отправке заголовков ответа HTTP клиенту. Это дает фильтру шанс изменить отправляемый клиенту ответ. Данное явление не полностью реализовано в текущей версии DSAPI. Параметр pEventData является указателем на экземпляр структуры FilterResponse.
Это событие происходит, когда стек HTTP близок к отправке данных ответа HTTP клиенту. Это дает фильтру шанс изменить отправляемые клиенту данные ответа. Это не полностью реализовано в текущей версии DSAPI. Параметр pEventData является указателем на экземпляр структуры FilterRawWrite.
Из описанных здесь событий для конструирования пользовательской реализации kFilterAuthenticate, kFilterUserNameList и kFilterAuthorized. Обратите внимание на тот факт, что вместо события kFilterAuthenticate может также использоваться kFilterAuthUser, хотя оно и является событием версии 5, которое поддерживается в Domino 6 в целях обеспечения обратной совместимости. Новые фильтры DSAPI должны использовать событие kFilterAuthenticate.
Функции DSAPI включены в инструментарий Lotus C API Toolkit, который может быть загружен с адреса:
Фильтр DSAPI скомпонован как общая библиотека (shared library) под UNIX и как DLL-файл под Win32. DSAPI поддерживается во всех платформах серверов Domino. Так как фильтр написан на языке С, вы можете использовать API языка С Notes для доступа к данным Domino либо другие интерфейсы С для доступа к другим системам. Детали компиляции и компоновки общей библиотеки отличаются в зависимости от платформы. Обратите внимание на тот факт, что инструментарий API языка С Lotus для Domino 6 не является обратносовместимым, означая тем самым, что программы, разработанные с применением инструментария 6.х, не будут работать в предшествующих шестой версиях Domino. Если вы имеете среду Domino R5 или смешанную среду R5 и Domino 6, вы должны использовать инструментарий R5.x.
Фильтр DSAPI является серверным расширением, и поэтому при доступе к базам данных Domino посредством API языка С фильтр имеет привилегии ID сервера.
Так как FilterContext. Когда поток обработает запрос, он передает этот экземпляр всем функциям фильтра, которые он вызывает. FilterContext содержит указатель privateContext, который вы можете использовать для хранения своей собственной структуры данных. Все специфические данные потока, которые фильтру необходимо обслуживать от события к событию, должны сохраняться в вашей структуре privateContext.
Вы должны применять функцию обратного вызова AllocMem для распределения в вашем фильтре динамической памяти. Вся память, распределенная AllocMem, автоматически освобождается, когда поток сервера завершает обработку запроса. Это упрощает очистку ресурсов вашего фильтра и гарантирует, что память освобождается, даже если поток закончился аварийно.
Установите фильтр посредством указания имени фильтра в записи Server поля имени файла фильтра DSAPI в пунктах меню Internet Protocols (интернет-протоколы) > HTTP table (Таблица HTTP). Вы можете указать только имя файла фильтра, если он расположен в каталогах программ или данных Domino; в противном случае вы должны указать
Инструментарий API языка С Domino 6 предоставляет для работы с маркерами LTPA две функции:
SECTokenValidate – проверка достоверности маркера LTPA SECTokenGenerate – генерирование маркера LTPA Эти две функции соответствуют расшифровке и шифрованию маркеров LTPA, описанных ранее в разделе, посвященном LTPA.
DSAPI обеспечивает достаточную гибкость для аутентификации Web-пользователя Domino с применением практически любого критерия. Такой критерий может основываться на сравнении имени и пароля в Domino или во внешнем каталоге LDAP, на сравнении представленного в cookie имени или на каком-либо другом механизме. Вместе с большой гибкостью присутствуют и издержки, связанные с обеспечением безопасности используемого механизма. Решать проблему таких издержек приходится разработчику DSAPI. Другая потенциальная проблема и издержки связаны с производительностью. К примеру, если DSAPI требуется соединение с каталогом из внешней области, то время поиска может чрезмерно влиять на производительность. Разработчик может либо предпочесть проверку кеша пользователя, либо игнорировать кеш и производить внешний поиск при каждом случае доступа.
Функции DSAPI не осуществляют непосредственный контроль элементов управления доступом Domino. Однако они разрешают прямую установку авторизованного имени пользователя, которое применяется затем для всех случаев доступа на этот сервер со стороны запроса HTTP, обрабатываемого фильтром DSAPI.
Разработчик способен предоставить полный контроль относительно того, как пользовательское имя может преобразовываться или ставиться в соответствие другому имени посредством установки "authname" в любое желаемое значение и формат. См. описанный ранее сценарий 1 для события kFilterAuthUser.
Для ID пользователей и паролей Domino 6 поддерживает заголовки HTTP, что позволяет вам применять сторонний Web-сервер в качестве входного для сервера Domino. Это свойство часто описывается как WebSphere Application Server plug-in (Плагин сервера приложений WebSphere) для Domino, что является отчасти дезориентирующим названием, так как это не то же самое, что и плагин (plug-in) аутентификации или Перехватчик доверительных связей [Trust Association Interceptor (TAI)] сервера приложений WebSphere, и также это не включает в себя плагин Domino, так как это только параметр файла notes.ini, который сообщает HTTP Domino о приеме в заголовках HTTP ID пользователей и паролей, относящихся по стилю к серверу приложений WebSphere. Реальный плагин для поддержки этой архитектуры
В целях поддержания принципа единого входа с применением заголовков HTTP на внутреннем сервере Domino, добавьте в файл NOTES.INI следующую строку:
HTTPEnableConnectorHeaders=1
Этот параметр позволяет задаче HTTP Domino обрабатывать специальные заголовки, добавленные к запросам плагином сервера приложений WebSphere для IIS или для IBM HTTP Server. Такие заголовки включают информацию о конфигурации входного сервера и о статусе аутентификации пользователей.
В качестве меры безопасности задача HTTP Domino игнорирует эти заголовки в том случае, если параметр файла NOTES.INI не разрешен. Это предотвращает имитацию плагина со стороны атакующего.
Необходимо понимать, что при использовании этой архитектуры для обеспечения безопасности канала между входным HTTP-сервером и сервером Domino должны быть использованы брандмауэры и ограничения по портам; в противном случае сервер Domino подвергается риску, потому что заголовки HTTP могут легко быть подделаны. Другими словами, обеспечьте безопасность канала "HTTP-сервер – HTTP Domino" таким образом, чтобы только HTTP-серверу было разрешено подключаться к порту Domino 80/443. Целостность этой архитектуры
При использовании поддержки плагина заголовков HTTP в Domino, последний возлагает обязанности по проведению аутентификации всех пользователей на входной HTTP-сервер.
Элементы управления доступом Domino при использовании для аутентификации заголовков HTTP зависимы от имен пользователей, предоставленных плагином на внешнем Web-сервере. Списки управления доступом (ACL) баз данных Domino по-прежнему используются для определения того, должен ли быть предоставлен пользователю доступ к заданному ресурсу. Так как аутентифицированное имя пользователя в заголовке обычно не является иерархическим именем Notes пользователя, то списки управления доступом баз данных должны содержать элементы, которые соответствуют предполагаемой форме имени пользователя в заголовке. Общим подходом при решении этой проблемы является разрешение анонимного доступа к базам данных Domino и доверие аутентификации и элементам управления доступом входного сервера, которые определены в его реестре безопасности для URL-адресов Domino.
Главным недостатком этого подхода является невозможность реализации элементов управления доступом на уровне документов, таких, как осуществление доступа к документам с правами читателя (reader) или автора (writer). Аналогично не могут быть использованы элементы управления доступом на уровне полей, такие, как формулы hide when (скрыть когда) в форме Domino, которые используют принадлежность к группам или роли групп. Так как документы Domino получают сгенерированные идентификаторы (ID документов и UNID), то непрактично пытаться осуществлять доступ и управлять им с применением URL-адресов.
Для преобразования имени пользователя из заголовка HTTP в иерархическое имя Notes может быть реализовано преобразование имен Notes. Так как обычно иерархическое имя Notes – это то, что применяется в ACL базы данных Domino, то для этого могут быть использованы списки управления доступом (ACL) Domino, обеспечивая тем самым соответствие требуемым для поддержки преобразования имен условиям. Дополнительную информацию относительно того, как Domino может преобразовывать имя из внешнего каталога LDAP в иерархическое имя Notes, можно найти в разделе 11.9.4, "Преобразование имен в Domino".
Для выделения и демонстрации производительности и важности решения по обеспечению единого входа в этом разделе предусмотрено подробное обсуждение на высоком уровне одного потенциального сценария
При базовом сценарии
Сейчас мы изучим, как бы эта новая инфраструктура функционировала, причем сначала рассмотрим основные операции взаимодействия между пользователем и сервером портала, как это показано на рис. 7.3.
(рис 7.3) Взаимодействие браузера и портала при использовании SSO с применением LTPAНа шаге "1-Аутентификация" пользователь осуществляет запрос портала и предоставляет набор полномочий аутентификации (
Далее для демонстрации того, как этот "кешированный" маркер LTPA может быть использован порталом, мы рассмотрим операции взаимодействия системы, представленные на рис. 7.4.
(рис 7.4) Взаимодействие портала и Domino при использовании SSO с применением LTPAВ этом наборе операций взаимодействия клиент в лице браузера запрашивает портлет Domino с сервера портала (1). Сервер портала знает, что для получения данных для портлета он должен осуществить доступ к Domino от имени пользователя, и поэтому он обращается к серверу мандатов и осуществляет выборку маркера LTPA, который был кеширован для пользователя по исходному регистрационному имени (2 3). После этого портал отправляет Domino запрос с маркером LTPA (4). При доверии со стороны Domino маркеру LTPA производится проверка по ACL для запрашиваемого ресурса на основе имени пользователя из маркера LTPA (5). При условии, что пользователь авторизован, Domino отправит данные назад серверу портала (6), который затем предоставляет их обратно пользователю как часть изначально запрошенного портлета.
Обратите внимание на то, что при таком взаимодействии отсутствует связь с сервером аутентификации. Однако это предполагает, что имя пользователя непосредственно включено в список ACL, причем возможно при разрешении преобразования имен Domino. Если ACL содержит группы, при наличии которых должна быть осуществлена проверка на предмет членства в них, то в этом случае может иметь место некая связь с сервером аутентификации.
Наконец, на рис. 7.5 мы имеем одну финальную схему для демонстрации взаимодействия в рамках
(рис 7.5) Взаимодействие браузера, портала и Sametime при использовании SSO с применением LTPAПри условии, что после этого пользователь изъявит желание присутствовать на встрече, браузер начнет непосредственно взаимодействовать с сервером Sametime (8), который может запросить у пользователя браузера его
Будем надеяться, этот пример помог продемонстрировать мощь однородного решения по организации единого входа, особенно в случае использования объединенной портальной инфраструктуры.
Мы обсудили четыре основных метода для поддержки
LTPA имеет преимущество, выражающееся в поддержке со стороны практически всех программных продуктов IBM Lotus, WebSphere и Tivoli
Сертификаты X.509 имеют преимущество, выражающееся в предоставлении двухфакторной аутентификации, но их недостатком является требование реализации центра сертификации в целях выпуска сертификатов для каждого пользователя либо плата за эту услугу третьей стороне. Управление сертификатами на рабочих станциях клиентов также может являться отрицательным моментом в случае работы пользователей с различных машин.
DSAPI имеет преимущество, выражающееся в абсолютной гибкости при проведении аутентификации пользователя, хотя она достаточно специфична для Domino. DSAPI требует большого опыта для разработки сложных фильтров.
Заголовки HTTP имеют преимущество, выражающееся в относительной легкости реализации; однако они приносят высокую степень риска для безопасности, если канал между входным HTTP-сервером и внутренним сервером Domino является не полностью безопасным. В большинстве случаев они реализуются в связке с системой управления доступом организации (Enterprise Access Management), которая централизованно управляет всем доступом к Web-ресурсам.
Наконец, при принятии решения относительно выбора одного или другого метода
DSAPI, либо на основе заголовков HTTP.Начнем с представления более строгого определения
"Механизм, с помощью которого единственное действие по аутентификации и авторизации пользователя может разрешить ему доступ ко всем компьютерам и системам, к которым этот пользователь имеет разрешение на доступ, без необходимости ввода множества паролей".
Это определение взято с Web-сайта компании The
Ключевым моментом здесь является то, что пользователю требуется войти в систему (пройти аутентификацию) для подключения к приложению только один раз, причем в контексте этой же сессии нет необходимости проходить аутентификацию повторно при доступе к другому приложению или серверу.
Этот подход предполагает появление определенного количества важных преимуществ, но имеет также и некоторые недостатки. Преимуществами для конечных пользователей являются следующие положения:
Преимущества для
Потенциальные недостатки
Сложность обеспечения credentials ), которые могут понять и правильно обработать ( accept ) все приложения. Также нам нужно иметь возможность проверить достоверность параметров доступа пользователя ( credentials )
C технической точки зрения существует несколько различных методов, или инструментов, которые могут быть использованы, чтобы обеспечить пользователям возможность использования
Все методы
В этом разделе мы обсудим четыре основных метода, используемых для поддержки
Обратите внимание на то, что мы проводим различие между понятием credentials )], хранящихся во множестве мест для использования различными приложениями. При таком сценарии у пользователей запрашивалась бы аутентификация для каждого приложения (или сервера), к которым они осуществляют доступ, несмотря на то, что теоретически они бы использовали для этого одни и те же ID и пароль.
Чтобы иметь единый пароль несмотря на то, что каждое приложение использует специализированное хранилище для ID и пароля ( credentials store ), идентификаторы ( ID ) пользователей и пароли должны быть каким-то образом синхронизированы. Так как же можно синхронизировать пароли в различных хранилищах (каталогах)? Самый простой ответ, это пользователи могут вручную поддерживать идентичность своих logon-имен и паролей для различных систем, если у них есть на это соответствующие полномочия. Конечно, это без сомнения, самый недружелюбный к пользователю подход, потому что нагрузка в этом случае полностью ложится на него. Могут ли пароли быть синхронизированы программно? В некоторых случаях могут, хотя на самом деле процесс синхронизации представляет из себя одновременную смену паролей.
Большинство процессов "синхронизации" паролей технически являются процессом одновременного изменения паролей, происходящим в фоновом режиме. К примеру, если вы разрешили синхронизацию паролей Notes и Windows, то при изменении вами своего пароля в Notes введенный новый пароль временно сохраняется в буфере, после чего автоматически передается процессу изменения пароля Windows в фоновом режиме. Процесс очень похож на процесс синхронизации пароля Notes и Domino интернет-паролей. Одновременное изменение эффективно там, где вам необходимо набрать пароль только один раз, и он автоматически будет передан второй парольной системе.
С точки зрения обеспечения безопасности, возможность синхронизации значения пароля из хранилища, непременно связано с возникновением очень нежелательных слабых мест в системе безопасности. Слабым местом в этом случае была бы возможность извлечения версии пароля пользователя в виде открытого текста для того, чтобы его можно было записать в другой каталог. Безопасные хранилища входных данных не хранят пароль в виде открытого текста, скорее они хранят хеш или зашифрованную версию пароля. Алгоритм хеширования не должен быть реверсивным. Так, чтобы у нас не было возможности прочитать из каталога значение хеша и конвертировать его в текст. А если мы просто перепишем хешированый пароль из одного каталога в другой, то второй каталог будет иметь "хеш"-значение пароля, которое не сможет быть воспроизведено в исходный пароль, и поэтому никогда не пройдет процесс аутентификации или "связывания" ( "bind" ).
Примечание. Domino генерирует salted хеш). Значение(величина) хеш не подразумевает переносимости
Если каталог предусматривает доступ администратора или программы для получения пароля в виде открытого текста, это не является безопасным.
Для понимания проблемы паролей и факта хранения хешированного значения пароля в "безопасных" каталогах, вам необходимо понять процесс аутентификации. Когда пользователь предоставляет регистрационное имя ( ID ) и пароль, строка пароля хешируется и затем сравнивается с значением хеша сохраненного в каталоге. Хорошим примером этого процесса является bind -запрос протокола LDAP, при использовании LDAP для хранения ID и пароля ( credentials ). Если полученный после ввода имени и пароля пользователя хеш соответствует хеш, сохраненному в каталоге, считается что "связывание" ( "bind" ) прошло успешно. Несмотря на то, что некоторые каталоги хранят как исходный пароль, так и его хеш-значение, безопасные каталоги не подразумевают доступ к исходному паролю; вы можете получить доступ только к хеш.
Рассмотрим следующий пример.
Пароль пользователя состоит из строки символов "password" и сохранен в IBM "[B@7a8ea817". Что случится, если мы попытаемся синхронизировать это хеш-значение с документом Person пользователя в каталоге Domino? Хеш-значение, которое сгенерирует наш сервер Domino когда мы войдем (log in) ( bind ) с паролем "password", будет выглядеть как "355E98E7C7B59BD810ED845AD0FD2FC4". Так как это значение не идентично хеш-значению из каталога LDAP, с которым мы синхронизировались ( "[B@7a8ea817" ), аутентификация с Domino будет неудачной.
Применение единого пароля и синхронизации паролей является подходом, который минимально пригоден для, возможно, двух различных клиентов, таких как пароли Notes и Windows. Это не тот подход, который мы рекомендуем для интеграции браузерных приложений. В оставшейся части этой лекции внимание будет сфокусировано на принципе единого входа (
Маркеры Lightweight Third
Маркер LTPA содержит данные, которые уникально идентифицируют пользователя, такие, как
Особые примечания относительно использования LTPA включают:
Условие относительно того, что все серверы приложений должны находиться в одном и том же домене DNS, не является ограничением, предъявляемым только LTPA. Маркер LTPA является cookie сеанса браузера, а свойства таких cookies определены в RFC-2965, который доступен по адресу:
http://www.ietf.org/rfc/rfc2965.txt
Этот RFC устанавливает, что агент пользователя (браузер) не предоставит cookie серверу, находящемуся в домене DNS, отличном от того, в котором находится выпустивший (установивший) cookie хост (сервер). Существуют прокси-архитектуры, которые могут распространяться за пределы отдельного домена DNS, но рассмотрение подобных развитых архитектур выходит за рамки данного курса.
Для преодоления проблемы наличия множества доменов DNS существуют некоторые обходные маневры. Важным для понимания понятием является то, что домен или некая область из cookie сеанса LTPA используется только браузером клиента, но не серверами приложений. Таким образом, ключом для решения этой проблемы является использование псевдонимов DNS способом, при котором браузер отправляет cookie всем серверам, вовлеченным в доверенную среду LTPA, даже если реально они находятся в других доменах. К примеру, если ваши серверы Domino находятся в домене alpha.com, а вы имеете сервер портала в домене beta.com со страницей, на которой пользователи могут получать свою почту iNotes посредством iframe, то в Domino R5 вам необходимо сконфигурировать виртуальные серверы таким образом, чтобы они работали так, как если бы находились в домене beta.com. В Domino 6 для beta.com используйте документы Internet Site. В любом случае вам необходимо убедиться в том, что для серверов Domino в домене beta.com существуют записи псевдонимов DNS.
Для обеспечения поддержки принципа единого входа между протоколами, такими, как HTTP и DIIOP (а также с сервером приложений IBM WebSphere), Domino предусматривает криптографический механизм на основе маркеров. Серверы, которые участвуют в обеспечении принципа единого входа, применяют зашифрованную "Web-конфигурацию "Web ) для совместного использования секретных данных в каталоге Domino в целях генерирования и проверки достоверности маркеров единого входа. Эта секретная информация используется сервером для проверки того, что представленный пользователем маркер был сгенерирован сервером, который совместно использует тот же секрет. В оставшейся части этой лекции мы ограничимся рассмотрением маркеров LTPA в WebSphere.
WebSphere использует формат, называемый Lightweight Third
Примечание. В среде, где WebSphere используется совместно с продуктами Lotus, или Tivoli, или обоими вместе, ключи LTPA должны генерироваться WebSphere и импортироваться в другие продукты. Когда взаимодействие с WebSphere не требуется, Domino использует для маркера единого входа свой собственный формат, который незначительно отличается от реализованного в WebSphere. Серверы, участвующие в Domino
При применении LTPA в качестве механизма аутентификации для аутентификации пользователя применяется доверенный сторонний сервер. В зависимости от того, выпущен ли уже для пользователя маркер, Web-сервер может выполнить одно из двух возможных действий. Этими двумя действиями, или механизмами, являются:
Пользователи подвергаются аутентификации один раз за время сеанса. Первоначальная аутентификация с использованием LTPA основана на имени и пароле, хранящихся в каталоге LDAP, когда каталогу доверяют все приложения, которые совместно используют cookie сеанса LTPA. Обратите внимание на то, что ID ) и пароль первоначальному серверу в среде LTPA, тот предоставляет этот
| Данные | Значение |
|---|---|
CookieName (Имя cookie) |
"LtpaToken" (Маркер LTPA) |
CookieValue (Значение cookie) |
Закодировано Base64 (Маркер LTPA) |
LtpaToken (Маркер LTPA) |
Зашифровано (Маркер аутентификации, совместно используемый ключ) с использованием 3DES |
AuthenticationToken (Маркер аутентификации) |
Данные пользователя+"%"+Дата истечения срока действия маркера+"%"+Закодировано Base64 (Цифровая подпись) |
|
Подписано (Данные пользователя, дата истечения срока действия маркера) с использованием секретного ключа LTPA (с применением RSA/SHA1) |
PrivateKey-ltpa (Секретный ключ LTPA) |
Секретный ключ (соответствующий открытому ключу, к которому могут получить доступ другие серверы) используется сервером LTPA для подписи данных аутентификации; этот секретный ключ должен быть доступен только серверу LTPA |
SharedKey (Совместно используемый ключ) |
Симметричный/совместно используемый ключ 3DES, который совместно применяется сервером LTPA и другими серверами для шифрования/расшифровки маркера |
UserData (Данные пользователя) |
Пары имени и значения, отделенные разделителем "$" (к примеру, "uid:"+ID пользователя) |
TokenExpirationDate (Дата истечения срока действия маркера) |
Число, представляющее время и дату истечения срока действия маркера. (Дата истечения срока действия маркера является числом миллисекунд, которые проходят начиная с полночи (00:00:00) 1 января 1970 г.) |
Обратите внимание на то, что внутри закодированной структуры находится цифровая подпись. Эта подпись сделана выпустившим маркер сервером с использованием секретного ключа сервера (в случае сервера Domino) или ключа, сгенерированного псевдослучайным образом (в случае сервера WebSphere).
Если пользователь уже имеет маркер LTPA, то затем маркер подвергается проверке достоверности со стороны получившего его Web-сервера. Web-сервер, в свою очередь, может запросить для проверки достоверности удостоверения личности (
Следующий пример отображает журнал отладки сервера Domino, выполняющего три шага по обработке полученного им маркера LTPA, сгенерированного WebSphere: декодирование кода Base64, расшифровка с применением совместно используемого секретного ключа (импортированного из WebSphere), и определение того, следует ли доверять имени пользователя в маркере как пользователю, прошедшему аутентификацию.
06/09/2003 05:53:39.53 PM [03071:00010-106510] SSO API> Decoding Websphere
style Single Sign-On token (LTPA).
06/09/2003 05:53:39.53 PM [03071:00010-106510] SSO API> Dumping memory
of encoded token [364 bytes].
00000000: 6C71 3150 4847 4536 3576 597A 6154 7878 'qlP1GH6Ev5zYTaxx'
00000010: 6F5A 534D 4262 6D70 3746 4643 6B56 3172 'ZoMSbBpmF7CFVkr1'
00000020: 5146 7045 5762 756E 6467 4532 6C68 314B 'FQEpbWnugd2EhlK1'
00000030: 3138 6E47 5164 5A41 634C 3965 3258 386C '81GndQAZLce9X2l8'
00000040: 2B7A 7239 7263 7976 5537 6332 4957 4F44 'z+9rcrvy7U2cWIDO'
00000050: 3755 4677 586D 2B6B 3768 7A31 3767 6976 'U7wFmXk+h71zg7vi'
00000060: 3672 5949 4672 7566 4C4D 636E 6236 665A 'r6IYrFfuMLnc6bZf'
00000070: 6E63 6A43 6246 4476 7159 476A 2F72 5445 'cnCjFbvDYqjGr/ET'
00000080: 6742 6C57 7779 7457 3671 6632 7467 3978 'BgWlywWtq62fgtx9'
00000090: 4947 6D71 4674 6643 7470 716D 6E56 5863 'GIqmtFCfptmqVncX'
000000A0: 6C43 5A4A 5050 4E48 4733 336E 6F69 757A 'ClJZPPHN3Gn3iozu'
000000B0: 4562 3777 475A 6136 3362 5138 6C4D 7554 'bEw7ZG6ab38QMlTu'
000000C0: 5475 7166 7438 5971 5269 5736 4949 6238 'uTfq8tqYiR6WII8b'
000000D0: 5839 6578 6552 714F 6378 6A35 4663 6435 '9XxeReOqxc5jcF5d'
000000E0: 4343 4E69 3076 4A6D 4372 686A 306C 6A51 'CCiNv0mJrCjhl0Qj'
000000F0: 4F57 6142 5955 7634 7771 3838 5A57 3230 'WOBaUY4vqw88WZ02'
00000100: 6F42 7671 3939 7231 5765 3068 4753 596B 'Boqv991reWh0SGkY'
00000110: 7A63 5862 4D31 4A4B 314E 4F6B 3576 4337 'czbX1MKJN1kOv57C'
00000120: 7449 654A 5253 3577 477A 4352 384D 684C 'ItJeSRw5zGRCM8Lh'
00000130: 6665 4E43 7365 504C 6B2B 7258 5157 7343 'efCNesLP+kXrWQCs'
00000140: 5866 3741 576C 534C 4630 6941 3035 6C76 'fXA7lWLS0FAi50vl'
00000150: 3247 356E 5076 2B68 4968 2F64 6955 3442 'G2n5vPh+hId/UiB4'
00000160: 5065 4F6F 324C 476D 3958 3D30 'ePoOL2mGX90='
06/09/2003 05:53:39.55 PM [03071:00010-106510] SSO API> Dumping memory
of encoded token before decryption step [272 bytes].
00000000: 53AA 18F5 847E 9CBF 4DD8 71AC 8366 6C12 '*Su.~.?.XM,qf..l'
00000010: 661A B017 5685 F54A 0115 6D29 EE69 DD81 '.f.0.VJu..)min.]'
00000020: 8684 B552 51F3 75A7 1900 C72D 5FBD 7C69 '..R5sQ'u..-G=_i|'
00000030: EFCF 726B F2BB 4DED 589C CE80 BC53 9905 'Ookr;rmM.X.NS<..'
00000040: 3E79 BD87 8373 E2BB A2AF AC18 EE57 B930 'y>.=s.;b/".,Wn09'
00000050: E9DC 5FB6 7072 15A3 C3BB A862 AFC6 13F1 '\i6_rp#.;Cb(F/q.'
00000060: 0506 CBA5 AD05 ADAB 829F 7DDC 8A18 B4A6 '..%K.-+-..\}..4'
00000070: 9F50 D9A6 56AA 1777 520A 3C59 CDF1 69DC 'P.Y*Vw..RY<qM\i'
00000080: 8AF7 EE8C 4C6C 643B 9A6E 7F6F 3210 EE54 'w..nlL;dn.o..2Tn'
00000090: 37B9 F2EA 98DA 1E89 2096 1B8F 7CF5 455E '97jrZ.... ..u|^E'
000000A0: AAE3 CEC5 7063 5D5E 2808 BF8D 8949 28AC 'c*ENcp^].(.?I.,('
000000B0: 97E1 2344 E058 515A 2F8E 0FAB 593C 369D 'a.D#X`ZQ./+.<Y.6'
000000C0: 8A06 F7AF 6BDD 6879 4874 1869 3673 D4D7 '../w]kyhtHi.s6WT'
000000D0: 89C2 5937 BF0E C29E D222 495E 391C 64CC 'B.7Y.?.B"R^I.9Ld'
000000E0: 3342 E1C2 F079 7A8D CFC2 45FA 59EB AC00 'B3Bayp.zBOzEkY.,'
000000F0: 707D 953B D262 50D0 E722 E54B 691B BCF9 '}p;.bRPP"gKe.iy<'
00000100: 7EF8 8784 527F 7820 FA78 2F0E 8669 DD5F 'x~...R xxz./i._]'
06/09/2003 05:53:39.55 PM [03071:00010-106510] SSO API> Dumping memory
of encoded token after decryption step [271 bytes].
00000000: 3A75 7375 7265 3A5C 7469 6F73 6573 2D63 'u:user\:itsosec-'
00000010: 646C 7061 632E 6D61 692E 7374 2E6F 6269 'ldap.cam.itso.ib'
00000020: 2E6D 6F63 5C6D 333A 3938 552F 4449 443D 'm.com\:389/UID=D'
00000030: 6948 6B6E 656C 4F2C 3D55 7250 646F 6375 'Hinkle,OU=Produc'
00000040: 6974 6E6F 6F2C 723D 6465 6F62 6B6F 2C73 'tion,o=redbooks,'
00000050: 3D63 7375 3125 3530 3235 3831 3733 3138 'c=us%10552183781'
00000060: 3635 4125 4274 4669 5238 3748 4858 6C4F '56%AtBiF8RH7XHOl'
00000070: 7A47 554F 5645 3575 7456 4172 597A 765A 'GzOUEVu5VtrAzYZv'
00000080: 6756 314E 5374 6548 3671 7573 554E 6872 'VgN1tSHeq6suNUrh'
00000090: 4E4B 3537 6632 6442 6A35 3161 6969 3479 'KN752fBd5ja1iiy4'
000000A0: 2F65 5868 7261 5A7A 4D6A 5977 6E6F 715A 'e/hXarzZjMwYonZq'
000000B0: 7868 2B43 4142 7434 7A52 5764 4B33 4E6A 'hxC+BA4tRzdW3KjN'
000000C0: 3044 6471 4B55 4C48 7450 5772 7150 2B48 'D0qdUKHLPtrWPqH+'
000000D0: 4655 7A33 4469 4F75 3261 4B4A 7349 5855 'UF3ziDuOa2JKIsUX'
000000E0: 6A69 684A 5567 594D 4335 6266 3335 3256 'ijJhgUMY5Cfb53V2'
000000F0: 6263 7034 4657 6851 6A35 7152 7636 3641 'cb4pWFQh5jRq6vA6'
00000100: 6339 4662 4441 5A58 7248 744D 414A 3D '9cbFADXZHrMtJA='
06/09/2003 05:53:39.56 PM [03071:00010-106510] SSO API> -LDAP Realm
= itsosec-ldap.cam.itso.ibm.com\:389
06/09/2003 05:53:39.56 PM [03071:00010-106510] SSO API> -Username
= UID=DHinkle/OU=Production/o=redbooks/c=us
06/09/2003 05:53:39.56 PM [03071:00010-106510] SSO API> -Expiration
Ticks = 1055218378666 [06/10/2003 12:12:58 AM].
06/09/2003 05:53:39.56 PM [03071:00010-106510] WebAuth> LOOKUP in view
$Users (user='UID=DHinkle/OU=Production/o=redbooks/c=us')
В этом примере обратите внимание на то, что Domino не осуществляет проверку достоверности цифровой подписи выпустившего сервера, когда определяет, что это маркер LTPA WebSphere. Domino интересует только три аспекта относительно принятого маркера LTPA:
Как правило, серверы WebSphere не имеют доступных Domino открытых/секретных ключей и, значит, без наличия общей инфраструктуры открытых ключей (PKI) для Domino не существует способа проверить достоверность цифровой подписи сервера WebSphere.
Основным соображением относительно обеспечения безопасности при использовании LTPA в смешанной среде WebSphere-Domino является защита совместно используемого секретного ключа. Если секретный ключ был скомпрометирован, то для осведомленного относительно этого факта лица становится возможным генерировать поддельные маркеры. Несмотря на всевозможные меры относительно защиты секретного ключа, теоретически он все еще уязвим для автономных атак в том случае, если достаточное количество маркеров получено посредством выборки (с помощью сетевого сниффинга) и кто-то может определить ключ с применением взлома по методу "грубой силы" (brute force
Управление доступом с использованием LTPA основано на содержащемся внутри маркера имени пользователя. Это имя будет отличительным именем [distinguished name (DN)] из каталога LDAP, применяемым в мандате пользователя. Если DN в маркере не соответствует элементу управления доступом [к примеру, элементу
Domino 6, а именно 6.0.2 и выше, обеспечивает чрезвычайно полезные возможности, которые позволяют устанавливать соответствие между содержащимся в маркере LTPA отличительным именем (DN) и другим именем в интересах управления доступом (осуществлять их преобразование). Сам по себе маркер LTPA не изменяется (не генерируется повторно), но аутентифицированное имя пользователя преобразовывается из отличительного имени LDAP в другое
Дополнительная информация о функциях преобразования различных имен в Domino описана в разделе 11.9.4, "Преобразование имен в Domino".
В дополнение к возможностям преобразования имен в Domino Tivoli WebSeal в связке с Tivoli
Если при конфигурировании инфраструктуры LTPA возникают проблемы, должны быть тщательно проанализированы значения различных параметров, связанных с LDAP. При использовании Lotus-технологий неправильная установка параметров "search filters" и "base dn" является причиной не менее 75 % связанных с LDAP-аутентификацией проблем.
Фактически для изменения связанных с аутентификацией фильтров поиска (search filters) существует множество мест, и все из них должны быть проверены тщательным образом:
Пример фильтра поиска Sametime показан на рис. 7.1.
(рис 7.1) Фильтр поиска LDAP SametimeЕсли после того, как вы исследовали соответствующие параметры LDAP, связанные с LTPA проблемы все еще случаются, то далее надо внимательно изучить файлы отладки и трассировки.
В NOTES.INI существует отладочная переменная, которая доступна в целях содействия в отыскании проблем с шифрованием и расшифровкой маркеров единственной подписи (DEBUG_SSO_TRACE_LEVEL=1. Для получения подробных дампов памяти, содержащих информацию о том, как шифруются и расшифровываются маркеры, установите DEBUG_ SSO_TRACE_LEVEL=2.
Примечание. Domino 6 может иметь различные конфигурации
Аутентификация клиента с использованием сертификатов X.509 предусматривает
Как правило, сертификат X.509 клиента защищен паролем, поэтому в данном случае использование сертификатов X.509 рассматривается как двухфакторный метод аутентификации: что-то у вас есть (сертификат на рабочей станции), а что-то вы знаете (пароль). Так как сертификаты могут также быть проверены, проконтролированы на предмет аннулирования и истечения срока действия, то сертификаты X.509 могут быть очень безопасным методом аутентификации пользователей. Однако в связи с тем, что сертификат X.509 сделан переносимым (или экспортируемым) и он может быть установлен в другие приложения или на другие рабочие станции, появляются как проблемы логистики для пользователя, так и потенциальные уязвимости в безопасности. Достоин упоминания тот факт, что Internet Explorer хранит сертификаты X.509 клиента в реестре Windows. Полное удаление сертификата с рабочей станции может потребовать ручного удаления его из реестра. Только недавно получили толчок в своем развитии смарт-карты как средства, обеспечивающие как переносимость, так и безопасность в хранении сертификатов клиента, причем несмотря на то, что недостаток, связанный с отсутствием повсеместного использования устройств считывания смарт-карт в персональных компьютерах, определенно затрудняет их широкое использование.
При аутентификации клиента клиент LDAP, а именно браузер, установленный на рабочей станции клиента, должен иметь цифровой сертификат (на основе стандарта X.509). Другими словами, сертификат X.509 содержит
В дополнение к SSL-аутентификации клиентов Web-браузеров для добавления к протоколам на основе соединений поддержки аутентификации на базе сертификатов X.509 может использоваться протокол SASL (Simple Authentication and Security Layer). Данный протокол содержит команду для идентификации и аутентификации пользователя по отношению к серверу. По выбору он может согласовывать уровень безопасности для последующего взаимодействия в рамках протокола. Если более точно, то существует как минимум семь различных типов поддерживаемой SASL аутентификации, но лишь тип аутентификации SASL "External" (Внешняя) использует сертификаты X.509. Спецификации SASL описаны в RFC-2222, который можно найти на адресу:
http://www.ietf.org/rfc/rfc2222.txt
Описание аутентификации и управления доступом в последующих двух разделах имеют отношение к процессу, используемому каталогом LDAP для аутентификации клиента. Это высокоуровневый обзор процесса при использовании каталога LDAP, причем описание поддержки X.509 в любом предоставленном продукте компании Lotus не обязательно.
После того как сервер получает команду аутентификации или любой ответ клиента, он может либо выдать вызов, либо отобразить ошибку или завершение. Если клиент получает вызов, он может выдать ответ либо прервать обмен в зависимости от профиля протокола.
Сейчас мы опишем последовательность аутентификации, которая выполняется с применением для аутентификации по протоколу SASL сертификатов X.509v3. Во время протокольного обмена в рамках аутентификации механизм SASL выполняет аутентификацию, передавая личность авторизации [известную как идентификатор пользователя (userid)] от клиента к серверу и договариваясь об использовании определенного механизмом уровня безопасности.
Когда сервер LDAP получает от клиента запрос связывания LDAP, он обрабатывает запрос следующим образом:
=EXTERNAL ) и тип аутентификации SSL является аутентификацией сервера и клиента, то сервер подтверждает, что сертификат клиента является действительным, был выпущен известным CA и в цепочке сертификатов клиента не существует недействительных или ldap_sasl_bind, не имеют значения NULL, то затем для последующих операций LDAP в качестве аутентифицированной личности используется NULL и LDAP_AUTH_NONE соответственно.Использование сертификатов клиента X.509 для
SASL поддерживает такое свойство, как прокси-авторизация (proxy authorization), которое позволяет аутентифицированным пользователям осуществлять запрос выполнения ими действий от лица другого пользователя. Этот шаг происходит после того, как пользователь получает
Интерфейс прикладного программирования Web-сервера Domino [Domino Web
Обратите внимание на то, что некоторые бизнес-партнеры IBM Lotus предлагают как стандартные, так и пользовательские решения для Web-аутентификации пользователей с применением DSAPI на основе инструментария интерфейса прикладного программирования на языке С Domino 6. За дополнительной информацией обратитесь к Web-сайту компании IBM.
Фильтр DSAPI позволяет вам настраивать обработку HTTP-запроса при возникновении определенных событий, например когда пользователь осуществляет доступ к ресурсу на сервере первый раз и вы желаете использовать специальную обработку данных аутентификации вместо обычной Web-аутентификации Domino. Процесс применяет набор предопределенных типов событий. Стек HTTP уведомляет фильтр DSAPI o событиях, после чего определенная разработчиком DSAPI логика принимает решение о том, что делать по факту наступления события. В настоящее время после события StartRequest существует 13 событий, которые могут быть перехвачены фильтром DSAPI. В зависимости от конструкции и ее реализации фильтр может поддерживать либо одно событие, либо некоторое их количество.
Реализация интерфейса DSAPI зависит от того, индикацию ("регистрацию") каких из событий фильтр поддерживает. Итак, фильтр получает от менеджера соединений стека уведомления только о тех событиях, о поддержке которых он заявил. Рис. 7.2 отображает, где фильтр DSAPI вступает в действие на HTTP-сервере Domino относительно другой обработки данных на Web-сервере.
(рис 7.2) Технологический процесс обработки стека интернет-протокола Domino 6В общем, события происходят в определенной последовательности. Они отражаются на состоянии стека HTTP на каждом из его шагов по обработке данных. Filter Init Data, когда фильтр загружен и проинициализирован). Типами методов запроса HTTP, при которых могут быть инициированы события, являются:
HEAD: метод HEAD часто используется для тестирования гипертекстовых ссылок в целях проверки достоверности, доступности и недавней модификации.GET: метод GET используется для выполнения выборки любой информации (в форме объекта), идентифицированной посредством Request-URL (URL-запроса).POST: метод POST требует, чтобы исходный сервер принимал объект, содержащийся в запросе, как новую субординантную информацию для ресурса, который идентифицирован посредством Request-URL в Requst-Line (Строка-статус).PUT: метод PUT требует, чтобы содержащийся в запросе элемент был сохранен по представленному Request-URL.DELETE: метод DELETE требует, чтобы исходный сервер удалил ресурс, идентифицированный посредством Request-URL.TRACE: метод TRACE.CONNECT: метод CONNECT.OPTIONS: метод OPTIONS.UNKNOWN: неизвестный метод запроса.BAD: неверный метод запроса. Ошибка.Типы событий описаны в последующих разделах в порядке их возникновения.
Это событие используется для того, чтобы информировать все загруженные в текущий момент фильтры о том, что запрос HTTP был принят и вскоре будет обрабатываться. На этом шаге фильтр может подготовиться к обработке запроса. Как правило, на этом шаге фильтр должен распределить свои собственные данные секретного контекста и требуемые ресурсы, необходимые для управления обработкой запроса. Параметр pEventData не используется, передается NULL. Любой фильтр, поддерживающий это событие, должен возвращать значение kFilterHandledEvent.
Все фильтры, загруженные на данный момент и поддерживающие это событие, уведомляются о том, что были изучены все входящие заголовки HTTP. Любой фильтр, которому необходима предварительная обработка входящих заголовков, может сделать это в данный момент времени. Обратите внимание на то, что в данный момент времени фильтр мог бы выбрать полное обслуживание запроса HTTP. Параметр pEventData является указателем на структуру FilterRawRequest.
Все фильтры, загруженные на данный момент и поддерживающие это событие, уведомляются о нем, когда стек HTTP заканчивает предварительный анализ всех входящих заголовков HTTP. Обратите внимание на то, что это отражает состояние, аналогичное состоянию в событии kFilterRawRequest, так как стек HTTP предварительно анализирует входящие заголовки HTTP перед тем, как начнет вызывать какой-либо фильтр. На этом шаге для полной обработки запроса вновь может быть выбран любой фильтр. Параметр pEventData является указателем на структуру FilterParsedRequest. Обратите внимание на то, что предусмотрены только две kFilterRawRequest.
Все фильтры, загруженные на данный момент и поддерживающие это событие, имеют возможность изменить URL-адрес для перенаправления запроса на некий другой ресурс. Если фильтр успешно переписывает URL-адрес для обработки и сервер обрабатывает этот новый URL-адрес, то после этого на уровне DSAPI обработка данного события заканчивается, а это означает, что другие фильтры в списке не будут уведомляться. Параметр pEventData является указателем на экземпляр структуры FilterMapURL. Обратите внимание на тот факт, что FilterMapURL используется также в таких событиях, как kFilterTranslateRequest и kFilterPostTranslate.
Это событие происходит, когда стек HTTP находится в фазе аутентификации процесса. Код фильтра способен осуществить просмотр запроса и pEventData является указателем на экземпляр структуры.
Это событие происходит, когда стек HTTP близок к генерированию списка имен групп пользователя. Это имена групп, членами которых является пользователь. Данное событие следует за событием kFilterAuthenticate. Этот фильтр может либо устанавливать, что сервер Domino заполняет список, добавляет или удаляет группы из списка, либо полностью обрабатывать событие (полностью самостоятельно генерировать список групп). Параметр pEventData в функции HttpEventProc является указателем на структуру FilterUserNameList.
Это событие происходит, когда стек HTTP близок к преобразованию URL-адреса пути в целевой ресурс. Фильтр может либо преобразовывать запрос с использованием своих собственных правил преобразования и построения соответствий, либо полностью обрабатывать запрос. Параметр pEventData является указателем на экземпляр структуры FilterMapURL.
Это событие происходит после того, как было обработано событие kFilterTranslateEvent. Для фильтра это возможность изменить целевой ресурс, к которому осуществляется доступ. Фильтр может изменять как путь целевого ресурса, так и тип построения соответствий. Фильтр может также выбрать полное обслуживание запроса. Параметр pEventData является указателем на экземпляр структуры FilterMapURL.
Это событие происходит после того, как имела место фаза аутентификации и был вычислен список имен групп пользователя. Фильтр может отвергнуть реализацию фазы авторизации по умолчанию и либо предоставить доступ к целевому ресурсу либо отказать в нем. Параметр pEventData является указателем на структуру FilterAuthorize. Она содержит информацию об используемом целевом ресурсе. Обратите внимание на тот факт, что фильтр может получить доступ к информации аутентифицированного пользователя путем применения служб при помощи ServerSupport с установленным флагом kGetAuthenticatedUserInfo. Это даст возможность пользователю получить доступ к аутентифицированному имени пользователя, а также к его или ее списку имен групп.
Если фильтр отказывает в доступе к целевому ресурсу, он должен отправить клиенту соответствующий ответ и установить поле isAuthorized структуры FilterAuthorize в значение 0. После этого он может вернуть либо kFilterHandledRequest, либо kFilter-HandledEvent. После этого на уровне DSAPI стеку HTTP будет подан сигнал на завершение обработки текущего запроса.
Это последний шаг в обслуживании запроса HTTP. Это событие может быть использовано для отклонения реализации обработки запроса по умолчанию. На этой стадии данные для ответа вычисляются и отправляются клиенту. Параметр pEventData является указателем на структуру FilterMapURL.
Это событие используется для информирования кода фильтра о том, что наступило время для обновления и освобождения ресурсов, выделенных для обработки заданного запроса HTTP. Параметр pEventData в этом случае имеет значение NULL.
Это событие заменено событием kFilterAuthenticate, но все еще поддерживается для обеспечения совместимости с написанными ранее фильтрами DSAPI. При этом событии фильтр осуществляет аутентификацию Web-пользователя. Параметр pEventData является экземпляром структуры FilterAuthenticate. Использование приведено в описанном ранее событии kFilterAuthenticate.
Это событие позволяет вам осуществлять настройку аутентификации Web-пользователей, которая зачастую является единственной частью реализации принципа единого входа в корпорации. В этом случае фильтр DSAPI уведомляется, когда Domino осуществляет аутентификацию пользователя. После этого фильтр DSAPI может проанализировать имя пользователя, проверить достоверность имен пользователей и паролей по отношению к действующей основной системе и, если проверка прошла успешно, уведомить Web-сервер Domino, что он обрабатывал аутентификацию пользователя, а также вернуть Domino
Далее приведено руководство по настройке выходных переменных и кодов возврата для общих сценариев аутентификации, когда eventData указывает на структуру FilterAuthenticate.
Сценарий 1. Фильтр был способен провести аутентификацию пользователя.
Установите eventData > authName в каноническое имя, установите eventData > authType в kAuthenticBasic или kAuthenticClientCert, а код возврата в kFilterHandledEvent.
Сценарий 2. Фильтр был неспособен провести аутентификацию пользователя, а другие фильтры или Domino должны двигаться вперед и предпринимать попытки проведения своей собственной аутентификации.
Установите код возврата в kFilterNotHandled.
Сценарий 3. Фильтр был неспособен провести аутентификацию пользователя, а другие фильтры или Domino не должны предпринимать попытки проведения своей собственной аутентификации.
Установите eventData > authType в kNotAuthentic, а код возврата в kFilterHandledEvent.
Это событие происходит, когда стек HTTP близок к отправке заголовков ответа HTTP клиенту. Это дает фильтру шанс изменить отправляемый клиенту ответ. Данное явление не полностью реализовано в текущей версии DSAPI. Параметр pEventData является указателем на экземпляр структуры FilterResponse.
Это событие происходит, когда стек HTTP близок к отправке данных ответа HTTP клиенту. Это дает фильтру шанс изменить отправляемые клиенту данные ответа. Это не полностью реализовано в текущей версии DSAPI. Параметр pEventData является указателем на экземпляр структуры FilterRawWrite.
Из описанных здесь событий для конструирования пользовательской реализации kFilterAuthenticate, kFilterUserNameList и kFilterAuthorized. Обратите внимание на тот факт, что вместо события kFilterAuthenticate может также использоваться kFilterAuthUser, хотя оно и является событием версии 5, которое поддерживается в Domino 6 в целях обеспечения обратной совместимости. Новые фильтры DSAPI должны использовать событие kFilterAuthenticate.
Функции DSAPI включены в инструментарий Lotus C API Toolkit, который может быть загружен с адреса:
Фильтр DSAPI скомпонован как общая библиотека (shared library) под UNIX и как DLL-файл под Win32. DSAPI поддерживается во всех платформах серверов Domino. Так как фильтр написан на языке С, вы можете использовать API языка С Notes для доступа к данным Domino либо другие интерфейсы С для доступа к другим системам. Детали компиляции и компоновки общей библиотеки отличаются в зависимости от платформы. Обратите внимание на тот факт, что инструментарий API языка С Lotus для Domino 6 не является обратносовместимым, означая тем самым, что программы, разработанные с применением инструментария 6.х, не будут работать в предшествующих шестой версиях Domino. Если вы имеете среду Domino R5 или смешанную среду R5 и Domino 6, вы должны использовать инструментарий R5.x.
Фильтр DSAPI является серверным расширением, и поэтому при доступе к базам данных Domino посредством API языка С фильтр имеет привилегии ID сервера.
Так как FilterContext. Когда поток обработает запрос, он передает этот экземпляр всем функциям фильтра, которые он вызывает. FilterContext содержит указатель privateContext, который вы можете использовать для хранения своей собственной структуры данных. Все специфические данные потока, которые фильтру необходимо обслуживать от события к событию, должны сохраняться в вашей структуре privateContext.
Вы должны применять функцию обратного вызова AllocMem для распределения в вашем фильтре динамической памяти. Вся память, распределенная AllocMem, автоматически освобождается, когда поток сервера завершает обработку запроса. Это упрощает очистку ресурсов вашего фильтра и гарантирует, что память освобождается, даже если поток закончился аварийно.
Установите фильтр посредством указания имени фильтра в записи Server поля имени файла фильтра DSAPI в пунктах меню Internet Protocols (интернет-протоколы) > HTTP table (Таблица HTTP). Вы можете указать только имя файла фильтра, если он расположен в каталогах программ или данных Domino; в противном случае вы должны указать
Инструментарий API языка С Domino 6 предоставляет для работы с маркерами LTPA две функции:
SECTokenValidate – проверка достоверности маркера LTPA SECTokenGenerate – генерирование маркера LTPA Эти две функции соответствуют расшифровке и шифрованию маркеров LTPA, описанных ранее в разделе, посвященном LTPA.
DSAPI обеспечивает достаточную гибкость для аутентификации Web-пользователя Domino с применением практически любого критерия. Такой критерий может основываться на сравнении имени и пароля в Domino или во внешнем каталоге LDAP, на сравнении представленного в cookie имени или на каком-либо другом механизме. Вместе с большой гибкостью присутствуют и издержки, связанные с обеспечением безопасности используемого механизма. Решать проблему таких издержек приходится разработчику DSAPI. Другая потенциальная проблема и издержки связаны с производительностью. К примеру, если DSAPI требуется соединение с каталогом из внешней области, то время поиска может чрезмерно влиять на производительность. Разработчик может либо предпочесть проверку кеша пользователя, либо игнорировать кеш и производить внешний поиск при каждом случае доступа.
Функции DSAPI не осуществляют непосредственный контроль элементов управления доступом Domino. Однако они разрешают прямую установку авторизованного имени пользователя, которое применяется затем для всех случаев доступа на этот сервер со стороны запроса HTTP, обрабатываемого фильтром DSAPI.
Разработчик способен предоставить полный контроль относительно того, как пользовательское имя может преобразовываться или ставиться в соответствие другому имени посредством установки "authname" в любое желаемое значение и формат. См. описанный ранее сценарий 1 для события kFilterAuthUser.
Для ID пользователей и паролей Domino 6 поддерживает заголовки HTTP, что позволяет вам применять сторонний Web-сервер в качестве входного для сервера Domino. Это свойство часто описывается как WebSphere Application Server plug-in (Плагин сервера приложений WebSphere) для Domino, что является отчасти дезориентирующим названием, так как это не то же самое, что и плагин (plug-in) аутентификации или Перехватчик доверительных связей [Trust Association Interceptor (TAI)] сервера приложений WebSphere, и также это не включает в себя плагин Domino, так как это только параметр файла notes.ini, который сообщает HTTP Domino о приеме в заголовках HTTP ID пользователей и паролей, относящихся по стилю к серверу приложений WebSphere. Реальный плагин для поддержки этой архитектуры
В целях поддержания принципа единого входа с применением заголовков HTTP на внутреннем сервере Domino, добавьте в файл NOTES.INI следующую строку:
HTTPEnableConnectorHeaders=1
Этот параметр позволяет задаче HTTP Domino обрабатывать специальные заголовки, добавленные к запросам плагином сервера приложений WebSphere для IIS или для IBM HTTP Server. Такие заголовки включают информацию о конфигурации входного сервера и о статусе аутентификации пользователей.
В качестве меры безопасности задача HTTP Domino игнорирует эти заголовки в том случае, если параметр файла NOTES.INI не разрешен. Это предотвращает имитацию плагина со стороны атакующего.
Необходимо понимать, что при использовании этой архитектуры для обеспечения безопасности канала между входным HTTP-сервером и сервером Domino должны быть использованы брандмауэры и ограничения по портам; в противном случае сервер Domino подвергается риску, потому что заголовки HTTP могут легко быть подделаны. Другими словами, обеспечьте безопасность канала "HTTP-сервер – HTTP Domino" таким образом, чтобы только HTTP-серверу было разрешено подключаться к порту Domino 80/443. Целостность этой архитектуры
При использовании поддержки плагина заголовков HTTP в Domino, последний возлагает обязанности по проведению аутентификации всех пользователей на входной HTTP-сервер.
Элементы управления доступом Domino при использовании для аутентификации заголовков HTTP зависимы от имен пользователей, предоставленных плагином на внешнем Web-сервере. Списки управления доступом (ACL) баз данных Domino по-прежнему используются для определения того, должен ли быть предоставлен пользователю доступ к заданному ресурсу. Так как аутентифицированное имя пользователя в заголовке обычно не является иерархическим именем Notes пользователя, то списки управления доступом баз данных должны содержать элементы, которые соответствуют предполагаемой форме имени пользователя в заголовке. Общим подходом при решении этой проблемы является разрешение анонимного доступа к базам данных Domino и доверие аутентификации и элементам управления доступом входного сервера, которые определены в его реестре безопасности для URL-адресов Domino.
Главным недостатком этого подхода является невозможность реализации элементов управления доступом на уровне документов, таких, как осуществление доступа к документам с правами читателя (reader) или автора (writer). Аналогично не могут быть использованы элементы управления доступом на уровне полей, такие, как формулы hide when (скрыть когда) в форме Domino, которые используют принадлежность к группам или роли групп. Так как документы Domino получают сгенерированные идентификаторы (ID документов и UNID), то непрактично пытаться осуществлять доступ и управлять им с применением URL-адресов.
Для преобразования имени пользователя из заголовка HTTP в иерархическое имя Notes может быть реализовано преобразование имен Notes. Так как обычно иерархическое имя Notes – это то, что применяется в ACL базы данных Domino, то для этого могут быть использованы списки управления доступом (ACL) Domino, обеспечивая тем самым соответствие требуемым для поддержки преобразования имен условиям. Дополнительную информацию относительно того, как Domino может преобразовывать имя из внешнего каталога LDAP в иерархическое имя Notes, можно найти в разделе 11.9.4, "Преобразование имен в Domino".
Для выделения и демонстрации производительности и важности решения по обеспечению единого входа в этом разделе предусмотрено подробное обсуждение на высоком уровне одного потенциального сценария
При базовом сценарии
Сейчас мы изучим, как бы эта новая инфраструктура функционировала, причем сначала рассмотрим основные операции взаимодействия между пользователем и сервером портала, как это показано на рис. 7.3.
(рис 7.3) Взаимодействие браузера и портала при использовании SSO с применением LTPAНа шаге "1-Аутентификация" пользователь осуществляет запрос портала и предоставляет набор полномочий аутентификации (
Далее для демонстрации того, как этот "кешированный" маркер LTPA может быть использован порталом, мы рассмотрим операции взаимодействия системы, представленные на рис. 7.4.
(рис 7.4) Взаимодействие портала и Domino при использовании SSO с применением LTPAВ этом наборе операций взаимодействия клиент в лице браузера запрашивает портлет Domino с сервера портала (1). Сервер портала знает, что для получения данных для портлета он должен осуществить доступ к Domino от имени пользователя, и поэтому он обращается к серверу мандатов и осуществляет выборку маркера LTPA, который был кеширован для пользователя по исходному регистрационному имени (2 3). После этого портал отправляет Domino запрос с маркером LTPA (4). При доверии со стороны Domino маркеру LTPA производится проверка по ACL для запрашиваемого ресурса на основе имени пользователя из маркера LTPA (5). При условии, что пользователь авторизован, Domino отправит данные назад серверу портала (6), который затем предоставляет их обратно пользователю как часть изначально запрошенного портлета.
Обратите внимание на то, что при таком взаимодействии отсутствует связь с сервером аутентификации. Однако это предполагает, что имя пользователя непосредственно включено в список ACL, причем возможно при разрешении преобразования имен Domino. Если ACL содержит группы, при наличии которых должна быть осуществлена проверка на предмет членства в них, то в этом случае может иметь место некая связь с сервером аутентификации.
Наконец, на рис. 7.5 мы имеем одну финальную схему для демонстрации взаимодействия в рамках
(рис 7.5) Взаимодействие браузера, портала и Sametime при использовании SSO с применением LTPAПри условии, что после этого пользователь изъявит желание присутствовать на встрече, браузер начнет непосредственно взаимодействовать с сервером Sametime (8), который может запросить у пользователя браузера его
Будем надеяться, этот пример помог продемонстрировать мощь однородного решения по организации единого входа, особенно в случае использования объединенной портальной инфраструктуры.
Мы обсудили четыре основных метода для поддержки
LTPA имеет преимущество, выражающееся в поддержке со стороны практически всех программных продуктов IBM Lotus, WebSphere и Tivoli
Сертификаты X.509 имеют преимущество, выражающееся в предоставлении двухфакторной аутентификации, но их недостатком является требование реализации центра сертификации в целях выпуска сертификатов для каждого пользователя либо плата за эту услугу третьей стороне. Управление сертификатами на рабочих станциях клиентов также может являться отрицательным моментом в случае работы пользователей с различных машин.
DSAPI имеет преимущество, выражающееся в абсолютной гибкости при проведении аутентификации пользователя, хотя она достаточно специфична для Domino. DSAPI требует большого опыта для разработки сложных фильтров.
Заголовки HTTP имеют преимущество, выражающееся в относительной легкости реализации; однако они приносят высокую степень риска для безопасности, если канал между входным HTTP-сервером и внутренним сервером Domino является не полностью безопасным. В большинстве случаев они реализуются в связке с системой управления доступом организации (Enterprise Access Management), которая централизованно управляет всем доступом к Web-ресурсам.
Наконец, при принятии решения относительно выбора одного или другого метода
DSAPI, либо на основе заголовков HTTP.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.