JBoss 4.0. Podręcznik Administratora

IDZ DO
PRZYKADOWY ROZDZIA
SPIS TRECI
KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG
TWJ KOSZYK
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK
CZYTELNIA
FRAGMENTY KSIEK ONLINE
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
JBoss 4.0. Podrcznik

administratora
Autor: The JBoss Group
Tumaczenie: Adam Bochenek, Piotr Rajca
ISBN: 83-246-0092-2
Tytu oryginau: JBoss 4.0 The Official Guide
Format: B5, stron: 616
Kompendium wiedzy o profesjonalnym serwerze aplikacji
Proces instalacji i konfiguracji
Tworzenie i udostpnianie aplikacji
Administrowanie serwerem i zabezpieczanie go
Technologia J2EE wici triumfy. Programici na caym wiecie stosuj j do tworzenia
rozbudowanych aplikacji korporacyjnych i e-commerce. Jednym z integralnych
elementw systemu zbudowanego w tej technologii jest odpowiedni serwer aplikacji.
Na rynku dostpnych jest kilka platform komercyjnych i zyskujcy na popularnoci
produkt open-source JBoss. JBoss to w peni profesjonalny serwer aplikacji J2EE,
ktry dziki bezpatnemu dostpowi znacznie redukuje koszty wdroenia systemw
informatycznych. Oczywicie to nie jedyna zaleta JBossa trudno pomin jego
stabilno i bezpieczestwo, wsparcie ze strony tysicy uytkownikw z caego wiata
i moduow budow, ktra pozwala na szybkie dodawanie kolejnych usug.
JBoss 4.0. Podrcznik administratora to wyczerpujce rdo informacji
o najnowszej edycji JBossa. Autorami s twrcy JBossa, co gwarantuje wysoki poziom
merytoryczny. Znajdziesz tu omwienie wszystkich zastosowa serwera oraz poznasz
sposoby tworzenia i wdraania aplikacji J2EE wykorzystujcych komponenty EJB,
serwlety, JMS i usugi sieciowe. Przeczytasz rwnie o bezpieczestwie serwera
i aplikacji oraz obsudze baz danych i transakcji. Ksika zawiera szczegowy opis
jdra JBossa, technologii Hibernate oraz programowania aspektowego.
Instalacja serwera
Domylna struktura katalogw
Pliki konfiguracyjne JBossa
Zastosowanie mechanizmw JNDI
Obsuga transakcji
EJB i serwlety
Stosowanie usugi JMS
Zabezpieczanie serwera JBoss
Korzystanie z usugi Tomcat
Mapowanie tabel baz danych na obiekty za pomoc Hibernate
Programowanie aspektowe
Poznaj architektur serwera JBoss i skonfiguruj go tak,
aby pracowa z maksymaln wydajnoci
Spis treci
O autorach ..................................................................................... 11
Wprowadzenie ................................................................................ 13
Rozdzia 1. Instalacja i kompilacja serwera JBoss ............................................. 23
Pobranie plikw binarnych ............................................................................................. 24
Warunki instalacji .................................................................................................... 24
Instalacja serwera przy uyciu pakietu zawierajcego wersj binarn ........................... 24
Struktura katalogw serwera JBoss .......................................................................... 25
Domylny zestaw konfiguracyjny serwera ............................................................... 25
conf\jboss-minimal.xml ........................................................................................... 27
conf\jboss-service.xml ............................................................................................. 27
conf\jboss.web ......................................................................................................... 27
conf\jndi.properties .................................................................................................. 27
conf\log4j.xml .......................................................................................................... 28
conf\login-config.xml ............................................................................................... 28
conf\server.policy ..................................................................................................... 28
conf\standardjaws.xml ............................................................................................. 28
conf\standardjboss.xml ............................................................................................. 28
conf\standardjbosscmp-jdbc.xml .............................................................................. 28
conf\xmdesc\*-mbean.xml ....................................................................................... 28
deploy\bsh-deployer.xml .......................................................................................... 28
deploy\cache-invalidation-service.xml ..................................................................... 29
deploy\client-deployer-service.xml .......................................................................... 29
deploy\ear-deployer.xml .......................................................................................... 29
deploy\ejb-deployer.xml .......................................................................................... 29
deploy\hsqldb-ds.xml ............................................................................................... 29
deploy\http-invoker.sar ............................................................................................ 29
deploy\jboss-aop.deployer ....................................................................................... 29
deploy\jboss-hibernate.deployer ............................................................................... 30
deploy\jboss-local-jdbc.rar ....................................................................................... 30
deploy\jboss-ws4ee.sar ............................................................................................. 30
deploy\jboss-xa-jdbc.rar ........................................................................................... 30
deploy\jbossjca-service.sar ....................................................................................... 30
deploy\jbossweb-tomcat50.sar ................................................................................. 30
deploy\jms\hsqldb-jdbc2-service.xml ...................................................................... 30
deploy\jms\jbossmq-destinations-service.xml .......................................................... 31
deploy\jms\jbossmq-httpil.sar .................................................................................. 31
JBoss 4.0. Podrcznik administratora

deploy\jms\jbossmq-service.xml .............................................................................. 31
deploy\jms\jms-ds.xml ............................................................................................. 31
deploy\jms\jms-ra.rar ............................................................................................... 31
deploy\jms\jvm-il-service.xml ................................................................................. 31
deploy\jms\uil2-service.xml ..................................................................................... 31
deploy\jmx-console.war ........................................................................................... 32
deploy\jmx-invoker-service.sar ................................................................................ 32
deploy\mail-ra.rar ..................................................................................................... 32
deploy\mail-service.xml ........................................................................................... 32
deploy\management\console-mgr.sar oraz web-console.war ................................... 32
deploy\monitoring-service.xml ................................................................................ 32
deploy\properties-service.xml .................................................................................. 33
deploy\scheduler-service.xml oraz schedule-manager-service.xml .......................... 33
deploy\sqlexception-service.xml .............................................................................. 33
deploy\uuid-key-generator.sar .................................................................................. 33
Sprawdzenie poprawnoci instalacji ............................................................................... 33
adowanie z serwera sieciowego ................................................................................... 35
Samodzielna kompilacja serwera JBoss na podstawie kodw rdowych .................... 37
Dostp do repozytorium CVS znajdujcego si w serwisie SourceForge ................ 37
Repozytorium CVS .................................................................................................. 38
Anonimowy dostp do CVS ..................................................................................... 38
Klient CVS ............................................................................................................... 39
Tworzenie dystrybucji serwera na podstawie kodu rdowego .............................. 39
Kompilacja serwera na podstawie pobranego
z repozytorium CVS kodu rdowego ................................................................... 39
Drzewo katalogw zawierajcych kod rdowy serwera ........................................ 40
Korzystanie z predefiniowanego zestawu testw JBoss ........................................... 40
Rozdzia 2. Jdro serwera JBoss ....................................................................... 45

JMX ................................................................................................................................ 45
Wprowadzenie do JMX ............................................................................................ 46
Serwer JBoss jako implementacja architektury JMX ..................................................... 52
Architektura adowania klas serwera JBoss ............................................................. 52
adowanie klas i typy jzyka Java ........................................................................... 52
Komponenty XMBean serwera JBoss ...................................................................... 74
Poczenie z serwerem JMX .......................................................................................... 81
Podgldanie serwera konsola JMX ..................................................................... 81
Poczenie z JMX za pomoc RMI .......................................................................... 85
Dostp do JMX z wiersza polece ........................................................................... 88
czenie z JMX za pomoc innych protokow ....................................................... 93
JMX jako mikrojdro ..................................................................................................... 93
Proces uruchamiania serwera ................................................................................... 94
Usugi MBean serwera JBoss ................................................................................... 95
Tworzenie usug MBean ........................................................................................ 107
Zalenoci i kolejno wdraania ........................................................................... 121
Architektura usug wdraajcych serwera JBoss .......................................................... 131
Obiekty wdraajce a classloadery ......................................................................... 134
Udostpnianie zdarze komponentw MBean przez protok SNMP .......................... 135
Usuga zamiany zdarzenia na puapk ................................................................... 137
Zdalny dostp do usug, wydzielone usugi wywoujce .............................................. 137
Przykad uycia wydzielonej usugi wywoujcej
usuga adaptora wywoa komponentu MBeanServer .................................... 140
JRMPInvoker transport przy uyciu protokou RMI/JRMP .............................. 147
PooledInvoker transport przy uyciu RMI/gniazdo ........................................... 148
IIOPInvoker transport przy uyciu RMI/IIOP ................................................... 148
Spis treci
5
JRMPProxyFactory tworzenie dynamicznych porednikw JRMP .................. 149
HttpInvoker RMI/HTTP Transport ................................................................... 149
HA JRMPInvoker klastrowy transport RMI/JRMP ........................................... 150
HA HttpInvoker klastrowy transport RMI/HTTP ............................................. 150
HttpProxyFactory tworzenie dynamicznych porednikw HTTP ..................... 151
Czynnoci pozwalajce udostpni dowolny interfejs RMI
przez protok HTTP ........................................................................................... 152
Rozdzia 3. Obsuga nazw ............................................................................... 155

Oglna charakterystyka JNDI ...................................................................................... 155
JNDI API ............................................................................................................... 156
J2EE i JNDI rodowisko komponentu aplikacji ................................................ 158
Architektura JBossNS .................................................................................................. 170
Fabryki tworzce obiekt kontekstu pocztkowego InitialContext ..................... 173
Dostp do JNDI przy uyciu HTTP ....................................................................... 178
Dostp do JNDI przy uyciu HTTPS ..................................................................... 181
Bezpieczny dostp do JNDI przy uyciu HTTP ..................................................... 183
Bezpieczny dostp do JNDI
za pomoc niezabezpieczonego kontekstu tylko do odczytu ............................... 185
Dodatkowe komponenty zwizane z usug nazw ................................................. 187
Rozdzia 4. Transakcje ................................................................................... 193

Transakcje i JTA wprowadzenie ............................................................................. 193
Blokowanie pesymistyczne i optymistyczne .......................................................... 194
Skadniki transakcji rozproszonej .......................................................................... 195
Dwufazowy protok XA ....................................................................................... 196
Wyjtki heurystyczne ............................................................................................. 196
Tosamo i gazie transakcji ............................................................................... 197
Obsuga transakcji w serwerze JBoss ........................................................................... 197
Podczenie menedera transakcji do serwera JBoss ............................................. 198
Domylny meneder transakcji .............................................................................. 199
Obsuga interfejsu UserTransaction ....................................................................... 200
Rozdzia 5. Komponenty EJB w JBoss ............................................................. 201

Komponenty EJB widziane z perspektywy klienta ...................................................... 201
Ustalenie konfiguracji penomocnika EJB ............................................................. 205
Komponenty EJB widziane z perspektywy serwera ..................................................... 210
Wydzielona usuga wywoujca dorczyciel da ........................................... 210
Transport przy uyciu RMI/JRMP w rodowisku klastrowym
JRMPInvokerHA ............................................................................................ 214
Transport przy uyciu RMI/HTTP w rodowisku klastrowym
HTTPInvokerHA ............................................................................................ 214
Kontener EJB ............................................................................................................... 216
Komponent MBean EJBDeployer .......................................................................... 216
Struktura kontenera bazujca na moduach ............................................................ 231
Blokowanie komponentw encyjnych i wykrywanie zakleszcze ............................... 243
Dlaczego blokowanie jest potrzebne ...................................................................... 244
Cykl ycia komponentu encyjnego ........................................................................ 244
Domylna strategia blokowania ............................................................................. 245
Dodatkowe obiekty przechwytujce i reguy blokowania ...................................... 245
Zakleszczenie ......................................................................................................... 246
Zaawansowana konfiguracja i optymalizacja ......................................................... 249
Uruchamianie komponentw w rodowisku klastrowym ....................................... 251
Rozwizywanie problemw ................................................................................... 251
Rozdzia 6. Usuga komunikatw JMS w JBoss ................................................ 253

Przykady uycia JMS .................................................................................................. 253
Przykad komunikacji typu punkt-punkt ................................................................ 254
Przykad komunikacji typu wydawca-abonent ....................................................... 256
Przykad komunikacji wydawca-abonent z obsug trwaego tematu .................... 261
Przykad komunikacji punkt-punkt poczonej
z uyciem komponentu sterowanego komunikatami (MDB) ............................... 264
Oglna charakterystyka JBossMQ ............................................................................... 271
Usugi warstwy wywoywa .................................................................................. 271
Usuga SecurityManager ........................................................................................ 272
Usuga DestinationManager ................................................................................... 272
Usuga MessageCache ........................................................................................... 272
Usuga StateManager ............................................................................................. 273
Usuga PersistenceManager ................................................................................... 273
Miejsce docelowe komunikatw ............................................................................ 273
Konfiguracja komponentw MBean wchodzcych w skad JBossMQ ........................ 274
Komponent org.jboss.mq.il.jvm.JVMServerILService .......................................... 275
Komponent org.jboss.mq.il.uil2.UILServerILService ............................................ 275
Komponent org.jboss.mq.il.http.HTTPServerILService ........................................ 278
Komponent org.jboss.mq.server.jmx.Invoker ........................................................ 279
Komponent org.jboss.mq.serwer.jmx.InterceptorLoader ....................................... 280
Komponent org.jboss.mq.sm.jdbc.JDBCStateManager ........................................... 280
Komponent org.jboss.mq.security.SecurityManager .............................................. 280
Komponent org.jboss.mq.server.jmx.DestinationManager .................................... 281
Komponent org.jboss.mq.server.MessageCache .................................................... 283
Komponent org.jboss.mq.pm.jdbc2.PersistenceManager ....................................... 284
Komponenty MBean reprezentujce miejsca docelowe ............................................. 286
Okrelanie dostawcy JMS dla kontenera MDB ............................................................ 290
Komponent org.jboss.jms.jndi.JMSProviderLoader .............................................. 291
Komponent org.jboss.jms.asf.ServerSessionPoolLoader ....................................... 293
Integracja z innymi dostawcami JMS ..................................................................... 293
Rozdzia 7. JCA w JBoss ................................................................................. 295

Oglna charakterystyka JCA ........................................................................................ 295
Architektura JBossCX .................................................................................................. 297
Komponent BaseConnectionManager2 .................................................................. 299
Komponent RARDeployment ................................................................................ 300
Komponent JBossManagedConnectionPool .......................................................... 301
Komponent CachedConnectionManager ................................................................ 302
Przykadowy szkielet adaptera zasobw JCA ........................................................ 303
Konfiguracja rde danych JDBC ............................................................................... 310
Konfiguracja oglnych adapterw JCA ........................................................................ 319
Rozdzia 8. Bezpieczestwo ............................................................................ 323

Deklaratywny model obsugi bezpieczestwa J2EE ..................................................... 323
Referencje element security-role-ref ................................................................. 324
Tosamo element security-identity ................................................................ 325
Role element security-role ................................................................................ 326
Uprawnienia wywoywania metod ......................................................................... 328
Uprawnienia dotyczce aplikacji sieciowych ......................................................... 331
Obsuga bezpieczestwa deklaratywnego w serwerze JBoss ................................. 333
Wprowadzenie do JAAS .............................................................................................. 334
Czym jest JAAS? ................................................................................................... 334
Spis treci
7
Model bezpieczestwa serwera JBoss .......................................................................... 339
Obsuga bezpieczestwa deklaratywnego w serwerze JBoss, odsona druga ......... 341
Architektura JBossSX .................................................................................................. 346
W jaki sposb JaasSecurityManager korzysta z JAAS .......................................... 348
Komponent JaasSecurityManagerService .............................................................. 351
Komponent JaasSecurityDomain ........................................................................... 353
Komponent adujcy plik XML z konfiguracj logowania .................................... 355
Komponent zarzdzajcy konfiguracj logowania ................................................. 357
Uywanie i tworzenie moduw logowania JBossSX ............................................ 358
Usuga DynamicLoginConfig ................................................................................ 382
Protok Secure Remote Password (SRP) .................................................................... 383
Udostpnianie informacji o hasach ....................................................................... 388
Szczegy dziaania algorytmu SRP ....................................................................... 390
Uruchamianie serwera JBoss z uyciem menedera bezpieczestwa Java 2 ................ 396
Zastosowanie protokou SSL przy uyciu JSSE ........................................................... 399
Konfiguracja serwera JBoss dziaajcego za firewallem .............................................. 403
Zabezpieczanie serwera JBoss ...................................................................................... 404
Usuga jmx-console.war ......................................................................................... 405
Usuga web-console.war ........................................................................................ 405
Usuga http-invoker.sar .......................................................................................... 405
Usuga jmx-invoker-adaptor-server.sar .................................................................. 405
Rozdzia 9. Aplikacje sieciowe ........................................................................ 407

Usuga Tomcat ............................................................................................................. 407
Plik konfiguracyjny serwera Tomcat server.xml ..................................................... 409
Element Connector ................................................................................................. 409
Element Engine ............................................................................................................ 412
Element Host ................................................................................................................ 412
Element DefaultContext ......................................................................................... 413
Element Logger ...................................................................................................... 413
Element Valve ........................................................................................................ 413
Korzystanie z protokou SSL w zestawie JBoss/Tomcat .............................................. 414
Ustalenie kontekstu gwnego aplikacji sieciowej ....................................................... 417
Konfiguracja hostw wirtualnych ................................................................................ 418
Dostarczanie treci statycznej ....................................................................................... 419
Poczenie serwerw Apache i Tomcat ........................................................................ 419
Praca w rodowisku klastrowym .................................................................................. 420
Integracja z innymi kontenerami serwletw ................................................................. 421
Klasa AbstractWebContainer ................................................................................. 422
Rozdzia 10. Inne usugi MBean ........................................................................ 431

Zarzdzanie waciwociami systemowymi ................................................................. 431
Zarzdzanie edytorem waciwoci .............................................................................. 432
Wizanie usug ............................................................................................................. 433
Planowanie zada ......................................................................................................... 437
Komponent org.jboss.varia.scheduler.Scheduler .................................................... 438
Usuga Log4j ................................................................................................................ 441
Dynamiczne adowanie klas RMI ................................................................................. 441
Rozdzia 11. Mechanizm CMP .......................................................................... 443

Przykadowy program .................................................................................................. 443
Wczanie rejestracji informacji testowych ............................................................ 445
Uruchamianie przykadw ..................................................................................... 445
Struktura jbosscmp-jdbc ............................................................................................... 447

Komponenty encyjne .................................................................................................... 449
Odwzorowania encji .............................................................................................. 451
Pola CMP ..................................................................................................................... 456
Deklaracja pl CMP ............................................................................................... 456
Odwzorowania kolumn pl CMP ........................................................................... 457
Pola tylko do odczytu ............................................................................................. 460
Nadzr dostpu do encji ......................................................................................... 460
Zalene klasy wartoci ........................................................................................... 462
Relacje zarzdzane przez kontener ............................................................................... 466
Abstrakcyjne metody dostpu do pl cmr-field ..................................................... 467
Deklaracja relacji ................................................................................................... 467
Odwzorowanie relacji ............................................................................................ 469
Deklarowanie zapyta .................................................................................................. 476
Deklarowanie metod wyszukujcych i wybierajcych ........................................... 477
Deklarowanie zapyta EJB-QL .............................................................................. 477
Przesanianie odwzorowania EJB-QL na SQL ....................................................... 478
JBossQL ................................................................................................................. 480
DynamicQL ............................................................................................................ 481
DeclaredSQL .......................................................................................................... 482
Zapytania EJB-QL 2.1 oraz SQL92 ....................................................................... 487
Niestandardowe metody wyszukujce BMP .......................................................... 488
adowanie zoptymalizowane ....................................................................................... 488
Scenariusz adowania ............................................................................................. 489
Grupy adowania .................................................................................................... 490
Odczyt z wyprzedzeniem ....................................................................................... 491
Proces adowania .......................................................................................................... 499
Opcje zatwierdzania ............................................................................................... 499
Proces adownia aktywnego ................................................................................... 500
Proces odczytu z opnieniem ............................................................................... 501
Zbiory wynikw odczytu z opnieniem ............................................................... 505
Transakcje .................................................................................................................... 505
Blokowanie optymistyczne .......................................................................................... 508
Polecenia encyjne oraz generacja klucza gwnego ..................................................... 512
Istniejce polecenia encji ....................................................................................... 513
Domylne ustawienia globalne serwera JBoss ............................................................. 515
Elementy ustawie globalnych ............................................................................... 517
Adaptacja rda danych .............................................................................................. 519
Odwzorowania typw ............................................................................................ 519
Odwzorowania funkcji ........................................................................................... 523
Odwzorowania typw ............................................................................................ 523
Odwzorowania typw uytkownika ....................................................................... 524
Rozdzia 12. Usugi sieciowe ............................................................................ 527

Punkty kocowe usug JAX-RPC ................................................................................. 527
Punkty kocowe komponentw Enterprise JavaBean .................................................. 533
Klienty usug sieciowych klient JAX-RPC ............................................................. 536
Referencje usug ........................................................................................................... 538
Rozdzia 13. Hibernate ..................................................................................... 543

MBean Hibernate ......................................................................................................... 543
Archiwa Hibernate ....................................................................................................... 545
Stosowanie obiektw Hibernate ................................................................................... 547
Stosowanie pliku HAR wewntrz pliku EAR ............................................................... 548
Mechanizm wdraania plikw HAR ............................................................................ 549
Spis treci
Rozdzia 14. Obsuga programowania aspektowego (AOP) ................................. 551

AOP w JBossie usugi w stylu EJB dla zwyczajnych obiektw Javy ...................... 551
Dlaczego AOP? ............................................................................................................ 551
Podstawowe pojcia zwizane z AOP .......................................................................... 553
Punkty cze i wywoania ..................................................................................... 553
Rady i aspekty ........................................................................................................ 553
Linie podziau ........................................................................................................ 554
Wstawienia oraz mieszanie .................................................................................... 557
Przygotowywanie aplikacji AOP na serwerze JBoss .................................................... 558
Kompilacja do postaci kodw bajtowych ............................................................... 558
Kompilacja adnotacji ............................................................................................. 558
Przygotowywanie AOP .......................................................................................... 559
Mechanizm wdraania aplikacji AOP na serwerze JBoss ............................................ 560
Instalacja najnowszej wersji usugi jboss-aop.deployer ............................................. 561
Konfiguracja usugi AOP ....................................................................................... 561
Biblioteka gotowych aspektw .............................................................................. 562
Pakowanie i wdraanie aplikacji AOP na serwerze JBoss ............................................ 563
Stosowanie gotowych aspektw ............................................................................. 565
Tworzenie wasnych aspektw ............................................................................... 567
Pakowanie i wdraanie niestandardowych aspektw ............................................. 568
Dodatek A Publiczna licencja GNU ................................................................. 573

Dodatek B Instalacja przykadw ................................................................... 579
Skorowidz ..................................................................................... 581
Rozdzia 8.
Bezpieczestwo
Zapewnienie odpowiedniego poziomu bezpieczestwa jest jednym z fundamentalnych
zada aplikacji korporacyjnych. Musimy by w stanie precyzyjnie okreli, kto moe
mie dostp do aplikacji i w jakim zakresie moe z oferowanych przez system operacji korzysta. Specyfikacja J2EE definiuje prosty, korzystajcy z pojcia roli model
bezpieczestwa dla komponentw sieciowych i EJB. Bezpieczestwem serwera JBoss
zajmuje si podsystem o nazwie JBossSX. Obsuguje on zarwno bazujcy na rolach
deklaratywny model bezpieczestwa, jak i pozwala na integracj za pomoc porednika ze specjalizowanym moduem bezpieczestwa. Domylna implementacja deklaratywnego modelu bezpieczestwa korzysta z technologii JAAS (ang. Java Authentication
and Authorization Service). Warstwa porednika bezpieczestwa pozwala na podczenie dowolnego, specjalizowanego moduu obsugi kwestii bezpieczestwa, ktrego nie
jestemy w stanie zdefiniowa za pomoc modelu deklaratywnego. Odbywa si to
w sposb przezroczysty z punktu widzenia komponentw biznesowych. Zanim przejdziemy do szczegw implementacyjnych serwera JBoss, przypomnimy opisane w specyfikacji modele bezpieczestwa dotyczce serwletw i komponentw EJB oraz podstawy technologii JAAS.
Deklaratywny model obsugi

bezpieczestwa J2EE
Specyfikacja J2EE zaleca stosowanie deklaratywnego modelu obsugi bezpieczestwa.
Nosi on nazw deklaratywnego, poniewa odpowiednie role i uprawnienia definiujemy
za pomoc standardowego deskryptora XML, informacji tych nie wstawiamy natomiast
do wntrza komponentw biznesowych. W ten sposb izolujemy kwestie bezpieczestwa od kodu warstwy logiki biznesowej. Mechanizmy zapewniajce bezpieczestwo
powinny by funkcj kontenera, w ktrym komponent jest wdroony, nie za czci
samego komponentu. Wyobramy sobie komponent, ktry reprezentuje i zapewnia
dostp do konta bankowego. Sprawy zwizane z zapewnieniem bezpieczestwa, rolami, prawami dostpu s zupenie niezalene od logiki, jak obiekt posiada. Zale one
przede wszystkim od specyfiki miejsca, w ktrym komponent jest wdroony.
324
Zabezpieczenie aplikacji J2EE zaley od konfiguracji wymaga, a ta znajduje si

w standardowych deskryptorach wdroenia. Za dostp do komponentw EJB odpowiada plik deskryptora ejb-jar.xml. W przypadku komponentw warstwy sieciowej jest to
deskryptor web.xml. W poniszych punktach omwimy znaczenie i sposb uycia podstawowych elementw konfigurujcych sposb zabezpieczenia aplikacji.
Referencje element security-role-ref

Zarwno komponentom EJB, jak te serwletom moemy przypisa jeden lub wiele elementw security-role-ref (rysunek 8.1). Stosujc ten element, deklarujemy, e komponent korzysta z wartoci role-name, traktujc j jako argument wywoania metody
isCallerInRole(String). Za pomoc metody isCallerInRole komponent moe sprawdzi, czy obiekt wywoujcy wystpuje w roli, ktra zostaa zadeklarowana przez element security-role-ref/role-name. Warto elementu role-name musi by zwizana
z elementem security-role za porednictwem elementu role-link. Typowe wykorzystanie metody isCallerInRole polega na dokonaniu operacji weryfikacji, ktrej nie da
si przeprowadzi przy uyciu standardowych, zwizanych z rol elementw method-permissions.
Rysunek 8.1.
Struktura elementu
security-role-ref
Na listingu 8.1 prezentujemy sposb uycia elementu security-role-ref w pliku deskryptora ejb-jar.xml.
Listing 8.1. Fragment deskryptora ejb-jar.xml ilustrujcy sposb uycia elementu security-role-ref

<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>ASessionBean</ejb-name>
...
<security-role-ref>
<role-name>TheRoleICheck</role-name>
<role-link>TheApplicationRole</role-link>
</security-role-ref>
</session>
</enterprise-beans>
...
</ejb-jar>
Rozdzia 8. Bezpieczestwo
325
Sposb wykorzystania elementu security-role-ref w pliku web.xml demonstruje listing 8.2

Listing 8.2. Fragment deskryptora web.xml ilustrujcy sposb uycia elementu security-role-ref
<web-app>
<servlet>
<servlet-name>AServlet</servlet-name>
...
<security-role-ref>
<role-name>TheServletRole</role-name>
<role-link>TheApplicationRole</role-link>
</security-role-ref>
</servlet>
...
</web-app>
Tosamo element security-identity

Za pomoc elementu security-identity istnieje moliwo okrelenia tosamoci, ktr posuguje si komponent EJB w chwilach, w ktrych wywouje metody innych komponentw. Struktur elementu security-identity pokazuje rysunek 8.2.
Rysunek 8.2.
Struktura elementu
security-identity
Tosamo komponentu wywoujcego metod moe by taka sama jak aktualna tosamo klienta, ktry z tego komponentu korzysta. Moemy jednak posuy si inn
rol. Osoba konstruujca aplikacj uywa elementu security-identity wraz z elementem podrzdnym use-caller-identity, chcc wskaza, e aktualna tosamo komponentu EJB ma by propagowana w ramach wywoa metod innych komponentw.
Opcja ta jest domylna i zostanie zastosowana take w sytuacjach, w ktrych element
security-identity nie bdzie w ogle zdefiniowany.
Rozwizanie alternatywne polega na uyciu elementu run-as/role-name. Okrelamy
w ten sposb inn rol, wskazan wanie przez warto elementu role-name, ktra
bdzie odpowiadaa tosamoci wysyanej podczas wywoywania metod innych komponentw EJB. Zauwa, e nie zmieniamy w ten sposb tosamoci obiektu wywoujcego, co pokazuje metoda EJBContext.getCallerPrincipal. Oznacza to natomiast,
e rolom obiektu wywoujcego przypisywana jest pojedyncza rola okrelona przez
326
warto elementu run-as/role-name. Jednym z zastosowa elementu run-as jest uniemoliwienie zewntrznym klientom dostpu do komponentw EJB, z ktrych chcemy
korzysta wycznie wewntrz aplikacji. Osigamy to na zasadzie przypisania elementom method-permission komponentu EJB takich rl, majcych zezwolenie na wywoanie metody, ktre nigdy nie zostan przydzielone klientom zewntrznym. Nastpnie
komponentom EJB, ktre upowanimy do wywoywania metod komponentw wewntrznych, przypisujemy t rol za pomoc elementu run-as/role-name. Listing 8.3
zawiera fragment deskryptora ejb-jar.xml, w ktrym uyty zosta element security-identity.
Listing 8.3. Fragment deskryptora ejb-jar.xml, ktry jest przykadem wykorzystania elementu
security-identity
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>ASessionBean</ejb-name>

<security-identity>
<use-caller-identity/>
</security-identity>
</session>
<session>
<ejb-name>RunAsBean</ejb-name>

<security-identity>
<run-as>
<description>A private internal role</description>
<role-name>InternalRole</role-name>
</run-as>
</security-identity>
</session>
</enterprise-beans>

</ejb-jar>
Role element security-role

Nazwa roli, do ktrej odwoujemy si z poziomu elementw security-role-ref lub
security-identity musi odpowiada ktrej z rl zdefiniowanych na poziomie aplikacji. Osoba wdraajca aplikacj tworzy takie role logiczne za pomoc elementw
security-role (rysunek 8.3). Warto elementu role-name jest nazw roli logicznej
zdefiniowanej w ramach aplikacji. Przykadem moe by rola Administrator, Architekt
czy Sprzedawca.
W specyfikacji J2EE wyranie podkrela si, by nie zapomina o tym, e role wymienione w deskryptorze wdroenia tworz pewien logiczny widok aplikacji, ktry odpowiada przyjtej strategii zapewnienia jej bezpieczestwa. Role zdefiniowane na poziomie deskryptora nie powinny by mylone z grupami, uytkownikami i uprawnieniami
istniejcymi na poziomie systemu operacyjnego, w ramach ktrego pracuje serwer
327
Rysunek 8.3.
Struktura elementu
security-role
aplikacyjny. Role z deskryptora wdroenia to skadniki aplikacji, taki jest te ich zasig. W przypadku aplikacji bankowej rolami takimi moe by np. KierownikZmiany,
Kasjer czy Klient.
W serwerze JBoss elementy security-role uywane s jedynie w celu przyporzdkowania wartoci security-role/role-name do roli logicznej, do ktrej odwouje si
komponent. Role przypisywane uytkownikowi s dynamiczn funkcj menedera bezpieczestwa aplikacji, co pokaemy podczas omawiania szczegw implementacyjnych
podsystemu JBossSX. JBoss nie wymaga definicji elementw security-role w celu
okrelenia uprawnie zezwalajcych na wywoywanie metod. Jednake tworzenie elementw security-role jest cigle zalecan praktyk, gwarantujc przenono aplikacji pomidzy rnymi serwerami aplikacyjnymi. Na listingu 8.4 widzimy element
security-role uyty wewntrz deskryptora ejb-jar.xml.
Listing 8.4. Fragment deskryptora ejb-jar.xml, ktry jest przykadem wykorzystania elementu
security-role
<ejb-jar>

<assembly-descriptor>
<security-role>
<description>The single application role</description>
<role-name>TheApplicationRole</role-name>
</security-role>
</assembly-descriptor>
</ejb-jar>
Na listingu 8.5 widzimy element security-role uyty w deskryptorze web.xml.

Listing 8.5. Fragment deskryptora web.xml, ktry jest przykadem wykorzystania elementu security-role

<web-app>

<security-role>
<description>The single application role</description>
<role-name>TheApplicationRole</role-name>
</security-role>
</web-app>
328
Uprawnienia wywoywania metod

Osoba wdraajca aplikacj moe za pomoc elementw method-permission wskaza
role, ktre uprawnione s do wywoywania metod zawartych w domowych i zdalnych
interfejsach komponentw EJB. Struktur elementu method-permission widzimy na
rysunku 8.4.
Rysunek 8.4.
Struktura elementu
method-permission
Kady element method-permission posiada jeden lub wiele elementw zagniedonych

role-name wskazujcych na role posiadajce uprawnienia, ktre pozwalaj wywoa zdefiniowane za pomoc elementw zagniedonych method metody komponentu EJB (rysunek 8.5). Zamiast elementu role-name moemy zdefiniowa element unchecked, deklarujc w ten sposb, e dostp do metod okrelonych za pomoc elementw method
maj wszyscy klienci, ktrzy zostali przez aplikacj uwierzytelnieni. Istnieje take element exclude-list definiujcy metody, ktrych nie mona wywoa. Metody komponentu EJB, ktre nie zostay wymienione na licie metod dostpnych, traktowane s domylnie w taki sam sposb, jakby byy wykluczone za pomoc elementu exclude-list.
Rysunek 8.5.
Struktura
elementu method
329
Istniej trzy dopuszczalne sposoby deklaracji elementu method:

Sposb pierwszy stosujemy wwczas, gdy chcemy wskaza wszystkie
metody interfejsu domowego i zdalnego danego komponentu EJB:

<method>
<ejb-name>EJBNAME</ejb-name>
<method-name>*</method-name>
</method>
Sposb drugi stosujemy, gdy chcemy wskaza metod o podanej nazwie
wchodzc w skad interfejsu domowego lub zdalnego danego komponentu EJB:

<method>
<method-name>METHOD</method-name>
</method>
Jeli istnieje kilka przecionych metod o tej samej nazwie, to element dotyczy
wszystkich.
Trzeci sposb jest najbardziej dokadny. Pozwala wskaza konkretn
metod nawet wwczas, gdy jej nazwa jest przeciona.

<method>
<method-name>METHOD</method-name>
<method-params>
<method-param>PARAMETER_1</method-param>

<method-param>PARAMETER_N</method-param>
</method-params>
</method>
Wskazana metoda musi by skadnikiem interfejsu domowego lub zdalnego

danego komponentu. Kady element method-param posiada warto, ktr jest
pena nazwa typu kolejnego parametru metody.
Opcjonalny element method-intf pozwala nam na dokonanie rozrnienia w przypadkach, gdy metody o identycznej sygnaturze wchodz w skad zarwno interfejsu domowego, jak i zdalnego.
Poniej, na listingu 8.6, prezentujemy przykad uycia elementu method-permission.
Listing 8.6. Fragment deskryptora ejb-jar.xml, ktry jest ilustracj uycia elementu method-permission
<ejb-jar>
<assembly-descriptor>
<method-permission>
<description>Role employee oraz temp-employee pozwalaj na dostp
do metod komponentu EmployeeService</description>
<role-name>employee</role-name>
<role-name>temp-employee</role-name>
<method>
<ejb-name>EmployeeService</ejb-name>
</method>
330

</method-permission>
<method-permission>
<description>Rola employee zezwala na wywoanie metod findByPrimaryKey,
getEmployeeInfo oraz updateEmployeeInfo(String) komponentu</description>
<role-name>employee</role-name>
<method>
<ejb-name>AardvarkPayroll</ejb-name>
<method-name>findByPrimaryKey</method-name>
</method>
<method>
<method-name>getEmployeeInfo</method-name>
</method>
<method>
<method-name>updateEmployeeInfo</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</method>
<method-permission>
<description>Rola admin pozwala na wywoanie dowolnej metody komponentu
EmployeeServiceAdmin</description>
<role-name>admin</role-name>
<method>
<ejb-name>EmployeeServiceAdmin</ejb-name>
</method>
<method-permission>
<description>Kady uwierzytelniony uytkownik posiada prawo wywoywania
dowolnej metody komponentu EmployeeServiceHelp
</description>
<unchecked/>
<method>
<ejb-name>EmployeeServiceHelp</ejb-name>
</method>
<exclude-list>
<description>Wdroenie nie zezwala na wywoanie adnej z metod fireTheCTO
komponentu EmployeeFiring
</description>
<method>
<ejb-name>EmployeeFiring</ejb-name>
<method-name>fireTheCTO</method-name>
</method>
</exclude-list>
</assembly-descriptor>
</ejb-jar>
331
Uprawnienia dotyczce aplikacji sieciowych

W aplikacjach sieciowych zasady bezpieczestwa i dostpu do zasobw rwnie okrelane s przy uyciu rl. W tym przypadku jednak prawa dostpu do zasobw przypisujemy rolom, korzystajc z wzorcw URL-i. Wskazuj one te treci, do ktrych nie
mona si swobodnie odwoywa. Cao definiujemy w pliku deskryptora web.xml
za pomoc elementu security-constraint (rysunek 8.6).
Rysunek 8.6.
Struktura elementu
security-constraint
Tre, ktra ma by chroniona, deklarujemy za pomoc jednego lub wielu elementw

web-resource-collection. Kady taki element zawiera moe list elementw podrzdnych url-pattern oraz list elementw http-method. Warto elementu url-pattern
zawiera wzorzec URL. Dostpne bd tylko te zasoby wskazane w daniu, ktre odpowiadaj wzorcowi. Warto elementu http-method wskazuje natomiast, jakie rodzaje
da HTTP bd obsugiwane.
332
Opcjonalny element user-data-constraint okrela wymagania, jakie stawiamy warstwie transportowej nadzorujcej poczenie pomidzy klientem a serwerem. Moemy
wybra wariant gwarantujcy integralno przesyanych danych (chronicy dane przed
ich modyfikacj w czasie transmisji) bd poufno danych (osoby trzecie nie bd
w stanie odczyta przesyanych danych). Elementu transport-guarantee okrela sposb ochrony danych w czasie komunikacji na linii klient-serwer. Moemy wybra jedn
z trzech wartoci tego elementu: NONE, INTEGRAL lub CONFIDENTIAL. Wybr pierwszej
opcji, NONE, oznacza, e aplikacja nie wymaga adnej ochrony przesyanych danych.
Opcj INTEGRAL stosujemy wwczas, gdy chcemy, by dane pomidzy serwerem a klientem nie mogy by podczas transportu zmodyfikowane. Warto CONFIDENTIAL zapewni
z kolei, e transmitowane dane s chronione przed ewentualn obserwacj prowadzon przez osoby trzecie. W wikszoci przypadkw wybr opcji INTEGRAL bd CONFIDENTIAL wie si z koniecznoci wczenia obsugi bezpiecznego protokou SSL.
Opcjonalny element login-config suy do definicji metody uwierzytelnienia, dziedziny, ktra ma by zwizana z aplikacj, oraz dodatkowych atrybutw, ktre s wymagane w czasie uwierzytelnienia z uyciem formularza. Model zawartoci tego elementu
zosta przedstawiony na rysunku 8.7.
Rysunek 8.7.
Element login-config
Element podrzdny auth-method okrela mechanizm uwierzytelniania klientw aplikacji sieciowej. Uzyskanie dostpu do dowolnego zasobu sieciowego, ktry jest chroniony, musi by poprzedzone zakoczon powodzeniem operacj uwierzytelnienia. Istniej cztery dopuszczalne wartoci elementu auth-metod: BASIC, DIGEST, FORM i CLIENT-CERT. Element podrzdny realm-name okrela nazw dziedziny uywanej podczas stosowania metod BASIC (podstawowa metoda uwierzytelniania) oraz DIGEST (odmiana metody podstawowej z zastosowaniem funkcji jednokierunkowej). Element podrzdny
form-login-config wskazuje stron logowania i stron bdu, ktre uyte zostan w czasie uycia metody uwierzytelniania bazujcej na formularzu. Jeli natomiast warto
elementu auth-method jest inna ni FORM, to cay wze form-login-config jest ignorowany. Na listingu 8.7 prezentujemy fragment deskryptora web.xml, w ktrym ustalamy, e wszystkie zasoby znajdujce si w katalogu /restricted wymagaj, by uytkownik,
333
ktry chce si do nich odwoywa, mia przypisan rol AuthorizedUser. Nie ma natomiast adnych wymaga odnonie warstwy transportowej, a uwierzytelnienie dokonywane jest przy uyciu metody podstawowej.
Listing 8.7. Fragment deskryptora web.xml, ktry jest ilustracj uycia elementu security-constraint
<web-app>

<security-constraint>
<web-resource-collection>
<web-resource-name>Secure Content</web-resource-name>
<url-pattern>/restricted/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>AuthorizedUser</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>

<login-config>
<auth-method>BASIC</auth-method>
<realm-name>The Restricted Zone</realm-name>
</login-config>

<security-role>
<description>Rola wymagana w celu uzyskania dostpu do zabezpieczonej treci
</description>
<role-name>AuthorizedUser</role-name>
</security-role>
</web-app>
Obsuga bezpieczestwa deklaratywnego

w serwerze JBoss
Przedstawione dotychczas elementy opisuj kwestie bezpieczestwa jedynie z perspektywy aplikacji. Ich wartoci definiuj pewne logiczne role, ktre osoba zajmujca
si wdroeniem musi przenie do rodowiska, w ktrym aplikacja ma funkcjonowa.
Specyfikacja J2EE nie omawia tych zagadnie szczegowo, wychodzc z zaoenia,
e szczegy zale ju od implementacji samego serwera aplikacyjnego. W JBossie
zwizanie logicznych rl ze rodowiskiem serwera wie si ze wskazaniem menedera
bezpieczestwa, ktry jest zgodny z modelem bezpieczestwa J2EE. Odbywa si to
za pomoc specjalnego deskryptora wdroenia. Wicej szczegw na temat konfigurowania warstwy bezpieczestwa omawiamy w podrozdziale Model bezpieczestwa
serwera JBoss.
334
Wprowadzenie do JAAS
Podsystem JBossSX bazuje na API JAAS (ang. Java Authentication and Aauthorization
Service). Zrozumienie dziaania implementacji JBossSX wymaga znajomoci podstaw
JAAS API. Dlatego zaczniemy od krtkiego wykadu na temat JAAS, ktry stanowi
przygotowanie do dalszej dyskusji na temat JBossSX.
Czym jest JAAS?

JAAS API 1.0 to zestaw pakietw i klas, ktre zaprojektowano z myl o operacjach
uwierzytelniania i autoryzacji. Stanowi one napisan w jzyku Java implementacj
standardowego, wymiennego moduu uwierzytelniajcego PAM (ang. Pluggable Authentication Module). Rozwizanie to jest zgodne i rozszerza standardow architektur
bezpieczestwa oraz zawarte tam mechanizmy uwierzytelniania uytkownikw. Modu JAAS by pocztkowo dostarczany w postaci rozszerzenia dla JDK 1.3. Poczwszy
od wersji 1.4, jest ju standardowym skadnikiem JDK. A poniewa JBossSX uywa
wycznie tych funkcji JAAS, ktre wi si z uwierzytelnianiem, to od tej chwili koncentrowa si bdziemy jedynie na zagadnieniach z tym zwizanych.
Uwierzytelnianie w JAAS odbywa si na zasadzie doczenia odpowiedniego moduu.
Pozwala to aplikacjom Javy pozostawa niezalenymi od aktualnie stosowanej technologii i mechanizmw uwierzytelniania. Dziki temu JBossSX moe pracowa w oparciu
o rne infrastruktury bezpieczestwa. Integracja z okrelon infrastruktur bezpieczestwa moe odbywa si bez koniecznoci dokonywania zmian w implementacji
menedera bezpieczestwa JBossSX. Jedynym elementem, ktry wymaga modyfikacji,
jest konfiguracja stosu uwierzytelniania uywanego przez JAAS.
Podstawowe klasy JAAS

Podstawowe klasy wchodzce w skad JAAS dziel si na trzy kategorie: klasy oglne,
klasy odpowiadajce za uwierzytelnianie i klasy odpowiadajce za autoryzacj. Poniej
prezentujemy jedynie klasy kategorii pierwszej i drugiej. To one implementuj funkcjonalno moduu JBossSX, ktr opisujemy w rozdziale.
Klasy oglne:
Subject (javax.security.auth.Subject)
Principal (java.security.Principal)
Klasy zwizane z uwierzytelnianiem:

Callback (javax.security.auth.callback.Callback)
CallbackHandler (javax.security.auth.callback.CallbackHandler)
Configuration (javax.security.auth.login.Configuration)
LoginContext (javax.security.auth.login.LoginContext)
LoginModule (javax.security.auth.spi.LoginModule)
335
Klasy Subject i Principal

Zanim nastpi autoryzacja, zezwalajca na dostp do zasobw, aplikacja musi najpierw
uwierzytelni rdo, z ktrego pochodzi danie. W JAAS zdefiniowane zostao pojcie podmiotu (ang. subject), ktry reprezentuje rdo dania. Odpowiadajca mu
klasa Subject jest kluczowym elementem JAAS. Obiekt Subject zawiera informacje
o pojedynczej encji, ktr moe by osoba lub usuga. Informacje te obejmuj tosamo encji, a take jej publiczne i prywatne dane uwierzytelniajce. JAAS API uywa
istniejcego ju w Javie interfejsu java.security.Principal, ktry suy do reprezentowania tosamoci. Obiekt tego typu przechowuje po prostu nazw.
W trakcie procesu uwierzytelnienia podmiotowi przypisuje si tosamo (klasa Principal) lub tosamoci, poniewa moe on mie ich kilka. Na przykad jedna osoba moe
posiada obiekt Principal odpowiadajcy jej nazwisku (np. Jan Kowalski), numerowi
identyfikacyjnemu (71061421421) czy te nazwie uytkownika, jak osoba si posuguje (jank). Wszystkie te dane pozwalaj nam skutecznie odrnia od siebie poszczeglne obiekty typu Subject. Istniej dwie metody, ktre zwracaj obiekty typu Principal
zwizane z obiektem Subject:
public Set getPrincipals() {...}
public Set getPrincipals(Class c) {...}
Pierwsza z nich zwraca wszystkie tosamoci podmiotu. Metoda druga zwraca natomiast tylko te obiekty Principal, ktre s instancjami typu c lub po c dziedzicz. Gdy
obiektw takich nie ma, zwracany jest zbir (Set) pusty. Zwr uwag, e interfejs
java.security.acl.Group jest rozszerzeniem interfejsu java.security.Principal. Dziki
temu, stosujc odpowiednie typy, moemy logicznie grupowa obiekty reprezentujce
tosamo.
Uwierzytelnienie podmiotu
Uwierzytelnienie podmiotu wie si z operacj logowania do JAAS. Procedura logowania skada si z nastpujcych etapw:
1. Aplikacja tworzy instancj typu LoginContext, przekazujc nazw konfiguracji
logowania oraz obiekt implementujcy interfejs CallbackHandler, ktremu
zostanie przekazana tablica obiektw typu Callback, ich zestaw odpowiada
konfiguracji moduu LoginModule.
2. Obiekt LoginContext na podstawie obiektu Configuration ustala list
wszystkich moduw LoginModule, ktre zgodnie z konfiguracj naley
zaadowa. Przy braku wskazanej konfiguracji domylnie uyta zostanie

konfiguracja o nazwie other.
3. Aplikacja wywouje metod LoginContext.login.
4. Metoda login odwouje si kolejno do wszystkich zaadowanych moduw
typu LoginModule. Kady z nich dokonuje prby uwierzytelnienia podmiotu,
wywoujc metod handle odpowiedniego obiektu CallbackHandler, ktra
zwraca informacje wymagane w procesie uwierzytelnienia. Parametrem

metody handle jest tablica obiektw typu Callback. Jeli operacja zakoczy
si sukcesem, LoginModule przypisuj podmiotowi odpowiedni tosamo
i dane uwierzytelniajce.
336

5. Obiekt LoginContext zwraca aplikacji status operacji uwierzytelnienia.
Sukcesowi odpowiada prawidowe zakoczenie metody login. Nieudane
logowanie sygnalizowane jest przez zgoszenie wyjtku LoginException.
6. Jeli operacja uwierzytelnienia si powiedzie, dostp do uwierzytelnionego
podmiotu aplikacja uzyskuje za pomoc metody LoginContext.getSubject.
7. Po opuszczeniu zakresu, w ktrym potrzebny jest uwierzytelniony podmiot,
moemy usun wszystkie zwizane z nim tosamoci i inne stowarzyszone

z podmiotem informacje. Suy do tego metoda LoginContext.logout.
Klasa LoginContext udostpnia zestaw podstawowych metod sucych do uwierzytelniania podmiotw i pozwala na tworzenie aplikacji w sposb niezaleny od uywanej
w danej chwili technologii obsugujcej warstw bezpieczestwa. LoginContext okrela aktualnie skonfigurowane usugi odpowiadajce za uwierzytelnianie na podstawie
danych zawartych w obiekcie Configuration. Poszczeglnie usugi uwierzytelniajce
reprezentowane s przez obiekty typu LoginModule. Jak wida, istnieje moliwo wczania rnych moduw logowania i nie wie si to z koniecznoci modyfikowania
kodu aplikacji. Poniszy fragment kodu prezentuje kolejne kroki, ktre pozwalaj aplikacji na uwierzytelnienie podmiotu, czyli obiektu Subject:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
CallbackHandler handler = new MyHandler();

LoginContext lc = new LoginContext("some-config", handler);
try {
lc.login();
Subject subject = lc.getSubject();
} catch(LoginException e) {
System.out.println("operacja uwierzytelnienia nie powioda si");
e.printStackTrace();
}
// Obszar zawierajcy operacje
// wymagajce uwierzytelnionego obiektu Subject
// ...
// Koniec obszaru, wywoujemy metod logout
try {
lc.logout();
} catch(LoginException e) {
System.out.println("bd podczas wylogowywania");
e.printStackTrace();
}
// Przykadowa klasa MyHandler
class MyHandler
implements CallbackHandler
{
public void handle(Callback[] callbacks) throws
IOException, UnsupportedCallbackException
{
for (int i = 0; i < callbacks.length; i++) {
if (callbacks[i] instanceof NameCallback) {
NameCallback nc = (NameCallback)callbacks[i];
nc.setName(username);
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
337
} else if (callbacks[i] instanceof PasswordCallback) {

PasswordCallback pc = (PasswordCallback)callbacks[i];
pc.setPassword(password);
} else {
throw new UnsupportedCallbackException(callbacks[i],
"Nieznany obiekt Callback");
}
}
}
}
Istnieje moliwo stworzenia wasnej implementacji interfejsu LoginModule. Dziki

temu da si integrowa aplikacje z rnymi zewntrznymi technologiami uwierzytelniania. Mona take stworzy acuch wielu moduw typu LoginModule; w ten sposb w procesie uwierzytelnienia bra moe udzia wiele rnych technologii. Na przykad jeden modu LoginModule moe dokona sprawdzenia nazwy uytkownika i jego
hasa, podczas gdy inny dokona uwierzytelnienia na podstawie wartoci podanych przez
czytnik kart bd urzdzenie biometryczne.
Cykl ycia moduu LoginModule okrelony jest przez obiekt LoginContext, ktry jest
tworzony przez klienta w celu wywoania jego metody LoginContext.login. Ten dwufazowy proces skada si nastpujcych krokw:
1. LoginContext tworzy wymienione w konfiguracji obiekty typu LoginModule,
korzystajc z ich bezparametrowego konstruktora.

2. Kady LoginModule jest nastpnie inicjalizowany za pomoc metody
initialize. Jej argument typu Subject nie moe wskazywa wartoci null.
Oto pena sygnatura tej metody: public void initialize(Subject subject,
CallbackHandler callbackHandler, Map sharedState, Map options).
3. Wywoywana jest metoda login, ktra rozpoczyna proces uwierzytelnienia.
Moe ona na przykad wywietli okienko suce do wprowadzenia nazwy

uytkownika i hasa, a nastpnie dokona weryfikacji tych danych za pomoc
odwoania do usugi NIS lub LDAP. Z kolei inna implementacja tej metody
moe korzysta z czytnika kart lub czytnika danych biometrycznych. Moemy
take pobra informacje o uytkowniku z systemu operacyjnego. Sprawdzenie
poprawnoci tosamoci uytkownika przez kady obiekt LoginModule nazywamy
pierwsz faz uwierzytelnienia JAAS. Sygnatura metody login jest nastpujca:
boolean login() throws LoginException. Zwrcenie wyjtku LoginException
sygnalizuje bd logowania. Zwrcenie przez metod wartoci true oznacza
natomiast, e operacja zakoczya si sukcesem. Zwrcenie wartoci false
informuje nas, e modu logowania powinien by zignorowany.
4. Gdy wszystkie operacje uwierzytelnienia w ramach obiektu LoginContext
zakocz si sukcesem, wywoywana jest metoda commit kadego moduu
LoginModule. Jeli wic faza pierwsza przebiegnie pomylnie, przechodzimy
do drugiej fazy uwierzytelnienia, w ktrej obiektowi typu Subject przypisywane
s obiekty typu Principal, a take publiczne i prywatne dane uwierzytelniajce.
338
Niepowodzenie w fazie pierwszej take wiza si bdzie z wywoaniem

metody commit. W takim przypadku jednak jej dziaanie bdzie inne, dokona
ona bowiem usunicia wczeniej podanych danych, takich jak identyfikator
i haso. Sygnatura metody commit jest nastpujca: boolean commit() throws
LoginException. Zgoszenie wyjtku LoginException oznacza problemy
z wykonaniem fazy drugiej. Warto true wskazuje na pomylne wykonanie
metody commit, podczas gdy zwrcona warto false mwi o tym, e modu
logowania powinien by zignorowany.
5. Gdy proces uwierzytelnienia za pomoc obiektu LoginContext zakoczy si
niepowodzeniem, w kadym z obiektw LoginModule wywoywana jest
metoda abort. Metoda abort usuwa wszystkie zwizane z uwierzytelnieniem
dane, ktre powstay w wyniku dziaanie metod login i initialize. Oto
sygnatura metody abort: boolean abort() throws LoginException. Zgoszenie
wyjtku LoginException oznacza problemy zwizane z wykonaniem czynnoci
zawartych w metodzie abort. Warto true wskazuje na pomylne wykonanie
metody abort, podczas gdy zwrcona warto false mwi o tym, e modu
logowania powinien by zignorowany.

6. Wywoanie metody logout obiektu LoginContext rwnie oznacza usunicie
informacji dotyczcych procesu uwierzytelnienia, tym razem jednak dzieje

si to po poprawnie zakoczonej operacji logowania. Wywoanie
LoginContext.logout powoduje rozpoczcie procesu, w ktrym wywoywane
s metody logout kolejnych obiektw typu LoginModule. Usuwane s wwczas
dane przyporzdkowane podmiotowi przez metod commit. Sygnatura metody
logout to: boolean logout() throws LoginException. Zgoszenie wyjtku
LoginException oznacza problemy zwizane z operacj wylogowywania.
Warto true wskazuje na pomylne wykonanie metody, podczas gdy warto
false mwi o tym, e modu logowania powinien by zignorowany.
Obiekt LoginModule wymaga informacji uwierzytelniajcych, a w celu ich pobrania
musi komunikowa si z uytkownikiem. Korzysta wwczas z obiektu typu CallbackHandler. Jednak to aplikacje implementuj interfejs CallbackHandler, instancj tego
typu przekazuj obiektowi LoginContext, ktry przesya j dalej, do moduw LoginModule. Modu LoginModule uywa obiektu CallbackHandler zarwno w celu pobrania
danych uytkownika (takich jak haso czy numer PIN), ale rwnie w celu wysania
uytkownikowi pewnych informacji (np. statusu operacji logowania). Poniewa to aplikacja wskazuje obiekt CallbackHandler, moduy LoginModule pozostaj niezalene od
tego, w jaki sposb przebiegaa bdzie interakcja z uytkownikiem. Na przykad implementacja obiektu CallbackHandler aplikacji posiadajcej graficzny interfejs uytkownika wywietli zapewne okienko dialogowe i poprosi uytkownika o wprowadzenie
danych. W przypadku rodowiska bez interfejsu graficznego, ktrym jest na przykad
serwer aplikacyjny, dane uwierzytelniajce mog by pobrane za pomoc API serwera.
Interfejs CallbackHandler definiuje tylko jedn metod, ktr musimy zaimplementowa:
void handle(Callback[] callbacks)
throws java.io.IOException,
UnsupportedCallbackException;
339
Ostatnim elementem procesu uwierzytelnienia, ktry chcemy opisa, jest interfejs Callback. Moduy typu LoginModule uywaj obiektw typu Callback w celu pobrania informacji wymaganej przez mechanizm uwierzytelnienia. Istnieje kilka predefiniowanych
implementacji tego typu, m.in. NameCallback i PasswordCallback, ktre widzielimy
w zaprezentowanym przed chwil przykadzie. Obiekt LoginModule przekazuje w czasie procesu uwierzytelniania tablic obiektw typu Callback bezporednio do obiektu
CallbackHandler jako parametr metody handle. Jeli aktualnie uywany obiekt typu
CallbackHandler nie wie, jak obsuy ktry z przekazanych mu obiektw typu Callback, zgaszany jest wyjtek UnsupportedCallbackException i proces logowania jest
przerywany.
Model bezpieczestwa serwera JBoss

Podobnie jak pozostae fragmenty architektury serwera JBoss model bezpieczestwa
rwnie zdefiniowany jest w postaci zestawu interfejsw, co umoliwia alternatywne
implementacje tego podsystemu. Istniej trzy interfejsy, ktre stanowi szkielet warstwy bezpieczestwa serwera JBoss: org.jboss.security.AuthenticationManager,
org.jboss.security.RealmMapping oraz org.jboss.security.SecurityProxy. Diagram
prezentujcy interfejsy podsystemu bezpieczestwa i ich relacje z kontenerem EJB widzimy na rysunku 8.8.
Rysunek 8.8. Kluczowe interfejsy modelu bezpieczestwa i ich zwizek z elementami kontenera EJB
serwera JBoss
Klasy zaznaczone na rysunku 8.8 kolorem szarym to interfejsy warstwy bezpieczestwa,

element niezaznaczony w ten sposb jest skadnikiem kontenera EJB. Model bezpieczestwa J2EE wymaga implementacji co najmniej dwch interfejsw: org.jboss.security.
AuthenticationManager i org.jboss.security.RealMapping. Charakterystyk wszystkich
interfejsw z rysunku 8.8 zamieszczamy poniej:
340

AuthenticationManager interfejs ten odpowiada za sprawdzenie poprawnoci
danych uwierzytelniajcych przypisanych do obiektw Principal. Obiekty
Principal okrelaj tosamo, przykadem moe by nazwa uytkownika,
numer pracownika, numer polisy ubezpieczeniowej. Zadaniem danych

uwierzytelniajcych jest potwierdzenie tej tosamoci, przykadem moe
by haso, klucz sesji, podpis cyfrowy. W celu sprawdzenia, czy podana
tosamo odpowiada danym uwierzytelniajcym, wywoujemy metod
isValid.
RealmMapping interfejs zajmuje si powizaniem tosamoci z rol. Metoda
getPrincipal na podstawie tosamoci uytkownika, znanej w rodowisku
operacyjnym, podaje rol znan w domenie aplikacji. Metoda doesUserHaveRole
sprawdza natomiast, czy okrelonej tosamoci ze rodowiska operacyjnego

jest na poziomie aplikacji przypisana rola.
SecurityProxy interfejs opisujcy wymagania, jakie stawiane s moduom
typu SecurityProxyInterceptor. SecurityProxy pozwala przenie na zewntrz
mechanizm kontroli wywoa metod obiektu domowego i zdalnego EJB.

SubjectSecurityManager ten interfejs wywodzi si bezporednio
z interfejsu AuthenticationManager, a dodatkowo pojawia si w nim
metoda zwracajca nazw domeny menedera bezpieczestwa oraz metoda

uwierzytelnionego w ramach biecego wtku obiektu Subject.
SecurityDomain rozszerzenie interfejsw AuthenticationManager,
RealmMapping i SubjectSecurityManager. Jest to prba stworzenia w miar
kompletnego interfejsu zwizanego z bezpieczestwem. Zawiera on w sobie

rwnie obiekt JAAS typu Subject, bazuje take na interfejsach
java.security.KeyStore oraz zdefiniowanych w ramach JSSE interfejsach
com.sun.net.ssl.KeyManagerFactory i com.sun.net.ssl.TrustManagerFactory.
Interfejs ten jest prb stworzenia bazy dla wielodomenowej architektury
bezpieczestwa, ktra bdzie w stanie lepiej obsuy aplikacje i zasoby
wdraane w stylu ASP.
Zauwa, e interfejsy AuthenticationManager, RealmMapping oraz SubjectSecurityManager nie maj swojego odpowiednika po stronie JAAS. Tak wic, cho podsystem
JBossSX w duym stopniu zaley od JAAS, nie dotyczy to podstawowych interfejsw, ktre podczas tworzenia modelu obsugi bezpieczestwa s implementowane.
A podsystem JBossSX to implementacja interfejsw doczanego moduu bezpieczestwa, ktre bazuj na JAAS. Najlepsz ilustracj tego faktu jest diagram zaprezentowany na rysunku 8.9. Skutkiem architektury, ktra opiera si na doczanym module,
jest moliwo implementacji takiej wersji podsystemu JBossSX, ktry korzysta z naszego wasnego menedera bezpieczestwa nie uywajcego JAAS. Przygldajc si
komponentom MBean podsystemu JBoss pokazanym na rysunku 8.9, dochodzimy do
wniosku, e jest to moliwe.
341
Rysunek 8.9.
Zwizek pomidzy
implementacj
podsystemu JBossSX
a warstw kontenera
EJB serwera JBoss
Obsuga bezpieczestwa deklaratywnego

w serwerze JBoss, odsona druga
Poprzedni punkt o takim samym tytule, ktry znajduje si we wczeniejszej czci niniejszego rozdziau, zakoczylimy stwierdzeniem, e za wczenie obsugi bezpieczestwa odpowiedzialny jest specyficzny dla serwera JBoss deskryptor wdroenia. Teraz
zaprezentujemy szczegy tej konfiguracji, poniewa jest ona czci oglnego modelu
bezpieczestwa JBoss. Na rysunku 8.10 widzimy struktur tych elementw specyficznych dla serwera JBoss deskryptorw jboss.xml oraz jboss-web.xml, ktre zwizane
s z konfiguracj warstwy bezpieczestwa.
Warto elementu security-domain okrela nazw JNDI implementacji menedera bezpieczestwa, ktry jest uywany przez serwer JBoss do obsugi kontenera EJB i kontenera aplikacji sieciowych. Musi to by obiekt, ktry implementuje dwa interfejsy:
AuthenticationManager i RealmMapping. Element zdefiniowany na najwyszym poziomie deskryptora staje si domen bezpieczestwa dla wszystkich komponentw EJB
wdraanego moduu. I jest to standardowy sposb jego uycia, poniewa czenie jednego moduu z kilkoma menederami bezpieczestwa powoduje wiele komplikacji dotyczcych wsppracy obiektw, utrudnia te administracj.
Wskazanie domeny bezpieczestwa dla pojedynczego komponentu EJB polega na zdefiniowaniu elementu security-domain na poziomie konfiguracji kontenera. Moemy
w ten sposb przedefiniowa warto zdefiniowan za pomoc elementu securitydomain znajdujcego si na najwyszym poziomie deskryptora.
342
Rysunek 8.10.
Podzbir elementw
deskryptorw jboss.xml
oraz jboss-web.xml
odpowiadajcych
za konfiguracj
warstwy bezpieczestwa
Element unauthenticated-principal okrela nazw obiektu Principal zwrconego przez

metod EJBContext.getUserPrincipal, gdy metod obiektu EJB wywouje uytkownik,
ktry nie zosta uwierzytelniony. Zauwa, e nie chodzi tutaj o przydzielenie specjalnych praw nieuwierzytelnionym obiektom wywoujcym. Celem takiego rozwizania
jest zezwolenie niechronionym serwletom i stronom JSP na dostp do niezabezpieczonych komponentw EJB. Rwnie dziki temu docelowy obiekt EJB moe uzyska dostp do niepustej referencji typu Principal obiektu wywoujcego, co umoliwia metoda getUserPrincipal.
Element security-proxy wskazuje na niestandardow implementacj obiektu porednika, ktry pozwala dokonywa weryfikacji da na zewntrz deklaratywnego modelu bezpieczestwa, bez koniecznoci wczania tej dodatkowej logiki do implementacji warstwy EJB. Moe to by implementacja interfejsu org.jboss.security.
343
SecurityProxy lub po prostu obiekt, ktry posiada implementacj metod interfejsu
domowego, zdalnego, lokalnego domowego i lokalnego. Nie jest wic wymagana implementacja adnego dodatkowego specjalnego interfejsu. Jeli klasa nie implementuje
interfejsu SecurityProxy, jej instancja musi zosta owinita przez implementacj
SecurityProxy, ktra oddeleguje wywoania do odpowiednich metod obiektu. Klasa
org.jboss.security.SubjectSecurityProxy jest przykadem implementacji interfejsu
SecurityProxy i jest uywana w domylnej konfiguracji podsystemu JBossSX.
Spjrzmy teraz na przykad wasnej implementacji interfejsu SecurityProxy w kontekcie bardzo prostego bezstanowego komponentu sesyjnego. Zadaniem naszego obiektu
bdzie nie dopuci do wywoania metody echo w przypadkach, gdy jej argumentem
jest wyraz skadajcy si z czterech liter. Taki rodzaj weryfikacji nie jest moliwy za
pomoc standardowego modelu bezpieczestwa bazujcego na rolach, nie jest bowiem
zwizany z prawami przypisanymi danemu uytkownikowi, dotyczy natomiast argumentw wywoywanej przez niego metody. Kod rdowy naszego porednika o nazwie EchoSecurityProxy znajduje si na listingu 8.8, cay przykad znajduje si wrd
przykadw doczonych do ksiki, w katalogu src\main\org\jboss\chap8\ex1.
Listing 8.8. Klasa EchoSecurityProxy bdca implementacj interfejsu SecurityProxy.
Zadaniem klasy jest weryfikacja wartoci argumentw metody echo
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
package org.jboss.chap8.ex1;
import
import
import
import
java.lang.reflect.Method;
javax.ejb.EJBContext;
org.apache.log4j.Category;
org.jboss.security.SecurityProxy;
/**
* Prosty przykad porednika typu SecurityProxy; demonstruje on weryfikacj
* wartoci atrybutw wywoywanych metod
*
* @author Scott.Stark@jboss.org
* @version $Revision: 1.2 $
*/
public class EchoSecurityProxy implements SecurityProxy {
Category log = Category.getInstance(EchoSecurityProxy.class);
Method echo;
public void init(Class beanHome, Class beanRemote, Object securityMgr)
throws InstantiationException {
init(beanHome, beanRemote, null, null, securityMgr);
}
public void init(Class beanHome, Class beanRemote, Class beanLocalHome,
Class beanLocal, Object securityMgr) throws InstantiationException {
log.debug("init, beanHome=" + beanHome + ", beanRemote=" + beanRemote
+ ", beanLocalhome=" + beanLocalHome + ", beanLocal="
+ beanLocal + ", securityMgr=" + securityMgr);
// pobranie metody echo, ktrej wywoania bdziemy testowa
try {
Class[] params = { String.class };
echo = beanRemote.getDeclaredMethod("echo", params);
344

34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
} catch (Exception e) {
String msg = "Nie znaleziona metoda echo(String)";
log.error(msg, e);
throw new InstantiationException(msg);
}
}
public void setEJBContext(EJBContext ctx) {
log.debug("setEJBContext, ctx=" + ctx);
}
public void invokeHome(Method m, Object[] args) throws SecurityException {
// Nie weryfikujemy dostpu do metod domowych
}
public void invoke(Method m, Object[] args, Object bean)
throws SecurityException {
log.debug("invoke, m=" + m);
// Sprawdzenie wywoania metody echo
if (m.equals(echo)) {
// Kontrola, czy argument skada si z czterech znakw
String arg = (String) args[0];
if (arg == null || arg.length() == 4) {
throw new SecurityException(
"Nieakceptowane s 4-literowe sowa");
}
// Nie wywoujemy metody invoke
}
}
}
Obiekt typu EchoSecurityProxy sprawdza, czy wywoywan metod komponentu jest

metoda echo(String). Jeli tak, pobieramy warto argumentu wywoania i sprawdzamy, czy jest ona wartoci null lub czy jej dugo wynosi 4. W obu przypadkach generujemy wyjtek SecurityException. Oczywicie przykad moe wydawa si nieco
sztuczny, ale chodzi wycznie o demonstracj opisywanego mechanizmu. W rzeczywistoci aplikacje dosy czsto dokonuj kontroli wartoci przesyanych argumentw pod
ktem bezpieczestwa. Zaprezentowany przykad stworzylimy jednak przede wszystkim po to, by pokaza, jak mona stworzy dodatkow warstw zabezpiecze wychodzc poza standardowy model deklaratywny, ktra nie wchodzi jednak w skad implementacji komponentw biznesowych. W ten sposb zadania zwizane z dodatkowymi
zabezpieczeniami moemy przekaza ekspertom od tych spraw, a samemu skoncentrowa si wycznie na logice biznesowej. Obiekty zwizane z tymi dwoma zagadnieniami mog by rozwijane niezalenie od siebie.
Na listingu 8.9 prezentujemy deskryptor jboss.xml, w ktrym instalujemy obiekt EchoSecurityProxy w roli porednika bezpieczestwa komponentu EchoBean.
345
Listing 8.9. Deskryptor jboss.xml, ktry wie obiekt porednika bezpieczestwa EchoSecurityProxy
z komponentem EchoBean
<?xml version="1.0"?>
<jboss>
<security-domain>java:/jaas/chap8-ex1</security-domain>
<enterprise-beans>
<session>
<ejb-name>EchoBean</ejb-name>
<jndi-name>chap8.EchoBean</jndi-name>
<security-proxy>org.jboss.chap8.ex1.EchoSecurityProxy</security-proxy>
</session>
</enterprise-beans>
</jboss>
Teraz stworzony przez nas obiekt porednika przetestujemy za pomoc klienta, ktry
wywoa metod echo komponentu EchoBean z dwoma argumentami: "Witaj" i "1234".
Program klienta widzimy poniej:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
package org.jboss.chap8.ex1;
import javax.naming.InitialContext;
import org.apache.log4j.Logger;
/**
* @author Scott.Stark@jboss.org
* @version $Revision: 1.2 $
*/
public class ExClient {
public static void main(String args[]) throws Exception {
Logger log = Logger.getLogger("ExClient");
log.info("Wyszukanie komponentu EchoBean");
InitialContext iniCtx = new InitialContext();
Object ref = iniCtx.lookup("chap8.EchoBean");
EchoHome home = (EchoHome) ref;
Echo echo = home.create();
log.info("Tworzymy obiekt Echo");
log.info("Echo.echo('Witaj') = " + echo.echo("Witaj"));
log.info("Echo.echo('1234') = " + echo.echo("1234"));
}
}
Pierwsze wywoanie metody echo powinno si uda. Drugie natomiast zawiedzie, poniewa argument skada si w tym przypadku z czterech znakw. Klienta uruchamiamy
za pomoc pokazanego poniej polecenia, wchodzc wczeniej do katalogu przyklady:
c:\JBoss\przyklady>ant -Dchap=chap8 -Dex=1 run-example
...
run-example1:
[copy] Copying 1 file to c:\jboss-4.0.1\server\default\deploy
[echo] Waiting for 5 seconds for deploy...
[java] [INFO,ExClient] Wyszukanie komponentu EchoBean
[java] [INFO,ExClient] Tworzymy obiekt Echo
346

[java] [INFO,ExClient] Echo.echo('Witaj') = Witaj
[java] java.rmi.ServerException: RemoteException occurred in server thread;
nested exception is:
[java]
java.rmi.AccessException: SecurityException; nested exception is:
[java]
java.lang.SecurityException: Nieakceptowane s 4-literowe sowa
...
[java]
at org.jboss.chap8.ex1.ExClient.main(ExClient.java:25)
[java] Caused by: java.rmi.AccessException: SecurityException; nested
exception is:
[java]
java.lang.SecurityException: Nieakceptowane s 4-literowe sowa
...
Wywoanie metody echo z argumentem "Witaj" zgodnie z przewidywaniami koczy

si sukcesem. Wywoanie z argumentem "1234", take zgodnie z oczekiwaniami, powoduje wywietlenie komunikatw wskazujcych na to, e zgoszony zosta wyjtek
(lista komunikatw celowo zostaa skrcona).
Kluczowym bdem jest oczywicie wyjtek SecurityException, mwicy o tym,
e Nieakceptowane s 4-literowe sowa. Jest on generowany z wntrza klasy EchoSecurityProxy w przypadku, gdy pojawia si wywoanie, do realizacji ktrego nie chcemy dopuci.
Architektura JBossSX
Z dotychczasowej dyskusji na temat oglnych zagadnie dotyczcych bezpieczestwa
serwera JBoss dowiedziae si ju, e podsystem JBossSX stanowi implementacj interfejsw definiujcych warstw bezpieczestwa. Ich poprawna implementacja jest podstawowym zadaniem JBossSX. A szczegy tej implementacji s bardzo interesujce,
poniewa oferuj nam wielk swobod w integrowaniu z istniejc infrastruktur, ktr
moe by zarwno baza danych czy serwer LDAP, jak te wyjtkowo zaawansowany
zestaw oprogramowania nadzorujcy kwestie bezpieczestwa. T elastyczno integracji osignito poprzez zastosowanie modelu moduw uwierzytelniania, ktry dostpny jest w ramach szkieletu JAAS.
Sercem struktury JBossSX jest klasa org.jboss.security.plugins.JaasSecurityManager.
To domylna implementacja interfejsw AuthenticationManager i RealmMapping. Na rysunku 8.11 wida sposb, w jaki JaasSecurityManager wsppracuje z warstw kontenera EJB i kontenera sieciowego, bazujc na elemencie security-domain deskryptora
wdroenia odpowiedniego komponentu.
Rysunek 8.11 przedstawia aplikacj, ktra skada si z komponentw sieciowych oraz
obiektw EJB, a zwizane s one z domen bezpieczestwa o nazwie jwdomain. Kontener sieciowy i kontener EJB korzystaj z usug odpowiadajcego za bezpieczestwo
obiektu przechwytujcego, ktry chroni zawarte w nich komponenty. Instancja uywanego menedera bezpieczestwa ustalana jest w momencie wdraania aplikacji, na
podstawie wartoci elementu security-domain, ktry znajduje si w deskryptorach
jboss.xml oraz jboss-web.xml. Na tej podstawie obiekt przechwytujcy odwouje si do
347
Rysunek 8.11.
Zalenoci midzy
wartoci security-domain deskryptora,
kontenerami
oraz menederem
bezpieczestwa
JaasSecurityManager
menedera bezpieczestwa. Gdy pojawia si danie dotyczce chronionego obiektu,

obiekt przechwytujcy deleguje zadanie weryfikacji dania do stowarzyszonego z kontenerem menedera bezpieczestwa.
Zawarta w JBossSX implementacja JaasSecurityManager dokonuje weryfikacji praw
dostpu na podstawie informacji zwizanych z obiektem Subject, ktry zostaje odpowiednio skonfigurowany przez moduy logowania odpowiadajce domenie wskazanej
za pomoc elementu security-domain. Ju za chwil zajmiemy si szczegami implementacyjnymi obiektu JaasSecurityManager.
348
W jaki sposb JaasSecurityManager korzysta z JAAS

JaasSecurityManager korzysta z pakietw JAAS w celu implementacji interfejsw
AuthenticationManager i RealmMapping. Mwic dokadnie, zachowanie obiektu ma
zwizek z dziaaniem moduw logowania, ktre zostay skonfigurowane w ramach

domeny bezpieczestwa, ktrej przypisana jest instancja typu JaasSecurityManager. Moduy logowania bior na siebie zadanie uwierzytelnienia tosamoci oraz przyporzdkowanie klientowi odpowiedniej roli. Tak wic moemy posugiwa si obiektem
JaasSecurityManager w ramach rnych domen, zmieniajc jedynie konfiguracje wczanych moduw logowania.
Dobr ilustracj szczegw dziaania obiektu JaasSecurityManager w czasie procesu
uwierzytelniania bdzie dokadny opis sytuacji, w ktrej klient wywouje metod obiektu
domowego komponentu EJB. Na pocztku zaoymy, e komponent EJB zosta ju
wdroony, a metody jego obiektu domowego zostay zabezpieczone przez odpowiedni definicj elementw method-permission znajdujcych si w deskryptorze ejb-jar.xml.
Komponentowi zostaa te przydzielona domena bezpieczestwa o nazwie jwdomain,
a odpowiada za to element security-domain deskryptora jboss.xml.
Schemat omawianej w niniejszym punkcie komunikacji pomidzy klientem i serwerem
przedstawiony zosta na rysunku 8.12.
Oto opis kolejnych krokw pokazanych na rysunku 8.12:
1. Klient wykonuje operacj logowania w celu ustalenia tosamoci i danych
uwierzytelniajcych. Sposb przeprowadzenia czynnoci zwizanych

z logowaniem zaley od aktualnej konfiguracji warstwy bezpieczestwa.
Logowanie przy uyciu JAAS zakada stworzenie instancji LoginContext
i przekazanie jej nazwy konfiguracji, ktra ma obowizywa. W naszym
przypadku korzystamy z konfiguracji domylnej o nazwie other. Pojedyncze
logowanie zwizuje tosamo i dane uwierzytelniajce z wszystkimi
majcymi nastpi za chwil wywoaniami metod komponentu EJB. Zwr
uwag na to, e opisywany proces moe nie uwierzytelnia klienta. Natura
logowania po stronie klienta zaley od konfiguracji moduu logowania
uywanego przez klienta. W opisywanym przykadzie konfiguracja o nazwie
other oznacza, e uyty zostanie modu ClientLoginModule (org.jboss.
security.ClientLoginModule). Jest to domylny modu logowania stosowany
po stronie klienta, jego zadaniem jest jedynie przekazanie warstwie wywoujcej
EJB nazwy uytkownika i hasa. Proces uwierzytelnienia odbdzie si pniej,
po stronie serwera. Tosamo uytkownika nie jest weryfikowana po stronie
klienta.
2. Klient uzyskuje dostp do obiektu domowego EJB i za jego pomoc dokonuje
prby stworzenia komponentu, a to oznacza, e wywoanie metody obiektu

domowego jest przesyane do serwera. Wywoanie to zawiera argumenty
podane przez klienta, jak rwnie tosamo i dane uwierzytelniajce ustalone
podczas realizacji pierwszego kroku.
Rysunek 8.12.
Kroki skadajce
si na proces
uwierzytelnienia
i autoryzacji dotyczcy
wywoania metody
obiektu domowego
komponentu EJB
3. Dziaajcy po stronie serwera obiekt przechwytujcy najpierw musi
uwierzytelni uytkownika, ktry jest odpowiedzialny za wywoanie.

Podobnie jak po stronie klienta, tutaj rwnie musi zosta wywoana
metoda logowania JAAS.
4. Domena bezpieczestwa, ktra odpowiada za ochron komponentu EJB,
odpowiada za wybr moduw logowania. Nazwa domeny uywana jest

do wskazania konfiguracji w konstruktorze obiektu LoginContext. W naszym
przykadzie jest to domena jwdomain. Jeli uwierzytelnienie uytkownika
zakoczy si sukcesem, stworzona zostanie instancja typu Subject,
z ktr zwizane zostan nastpujce obiekty:
Obiekt java.security.Principal, ktry okrela tosamo klienta

znan w rodowisku warstwy bezpieczestwa wdroenia.
349
350
Obiekt typu java.security.acl.Group o nazwie Roles reprezentujcy

zdefiniowane na poziomie domeny role przypisane uytkownikowi.
Obiekty org.jboss.security.SimplePrincipal odpowiadaj nazwom rl.
Kady obiekt tego typu jest bazujc na acuchu znakw implementacj
typu Principal. Role te porwnywane s z rolami przypisanymi do metod
na poziomie deskryptora ejb-jar.xml, korzystamy z nich w implementacji
metody EJBContext.isCallerInRole(String).
Opcjonalny obiekt typu java.security.acl.Group o nazwie CallerPrincipal,

ktry zawiera pojedynczy obiekt org.jboss.security.SimplePrincipal
odpowiadajcy tosamoci obiektu wywoujcego domeny aplikacji.
Jedynym elementem grupy CallerPrincipal bdzie warto zwracana
przez metod EJBContext.getCallerPrincipal(). Celem takiego
przyporzdkowania jest zwizanie obiektu Principal znanego w warstwie
bezpieczestwa wdroenia z obiektem Principal o nazwie znanej aplikacji.
W przypadku braku obiektu CallerPrincipal, rodowisko wdroenia uywa
nazwy zwrconej przez metod getCallerPrincipal, czyli wartoci
odpowiadajcej tosamoci znanej na poziomie domeny aplikacji.
Ostatnim krokiem wykonywanym przez obiekt przechwytujcy jest sprawdzenie, czy

uwierzytelniony uytkownik posiada odpowiednie uprawnienia pozwalajce mu wywoa okrelon metod. Proces autoryzacji przebiega nastpujco:
Z kontenera EJB pobierane s nazwy rl zezwalajcych na wywoanie metody
komponentu EJB. Role te zdefiniowane s w deskryptorze ejb-jar.xml za pomoc

elementw role-name wchodzcych w skad wszystkich elementw method-permission zwizanych z dan metod.
Jeli nie znaleziono adnych przypisanych metodzie rl, lub gdy nazwa
metody zawarta jest w ramach elementu exclude-list, to dostp do metody
jest blokowany. W przeciwnym wypadku obiekt przechwytujcy wywouje

metod doesUserHaveRole menedera bezpieczestwa, sprawdzajc, czy wrd
upowanionych rl znajduje si rola przypisana uytkownikowi. Proces
weryfikacji polega na tym, e przegldane s kolejne role i sprawdza si,
czy grupa Roles podmiotu Subject zawiera obiekt SimplePincipal wskazujcy
na rol o odpowiedniej nazwie. Zezwolenie na dostp do metody jest udzielane
wwczas, gdy dowolna rola jest elementem grupy Roles. W przeciwnym razie
nastpuje odmowa dostpu.
Jeli komponentowi EJB przypisano dodatkowy obiekt porednika
bezpieczestwa, wywoanie metody jest do niego delegowane. Jeli porednik

stwierdzi, e dostp do metody powinien by zabroniony, zgosi wyjtek
java.lang.SecurityException. Nie generujc wyjtku tego typu, wyraamy
zgod, by wywoanie doszo do skutku. Sam obiekt wywoania trafia
do nastpnego obiektu przechwytujcego. Zwr uwag na to, e obiekt
SecurityProxyInterceptor obsuguje ten etap, a dodatkowy obiekt
przechwytujcy nie jest na rysunku 8.12 pokazany.
Kade wywoanie metody chronionego komponentu EJB lub te danie dostpu do
zabezpieczonego skadnika aplikacji sieciowej wymaga uwierzytelnienia i autoryzacji
klienta wysyajcego to danie. Informacje zwizane z bezpieczestwem s traktowane
351
jako bezstanowy atrybut dania, ktry musi by przekazany i sprawdzony przy kadej operacji. A w czasie intensywnej komunikacji pomidzy klientem i serwerem czynnoci te mog okaza si kosztowne. Dlatego te obiekt JaasSecurityManager wprowadza pojcie bufora uwierzytelniania, w ktrym przechowywane s informacje dotyczce
poprzednich, zakoczonych powodzeniem operacji logowania. Moemy nawet w ramach konfiguracji JaasSecurityManager wskaza obiekt, ktry bdzie peni funkcj takiego bufora, piszemy o tym w kolejnym punkcie. Jeli elementu tego nie zdefiniujemy,
uyty bdzie bufor domylny przechowujcy wspomniane dane przez okrelony czas.
Komponent JaasSecurityManagerService
Komponent MBean JaasSecurityManagerService to usuga zarzdzajca menederami bezpieczestwa. I cho nazwa komponentu zaczyna si od Jaas, to zarzdzane
przez ni menedery bezpieczestwa nie musz w swej implementacji odwoywa si
do usug JAAS. Nazwa wzia si std, e domylnym menederem bezpieczestwa
jest obiekt JaasSecurityManager. Podstawowym zadaniem usugi JaasSecurityManagerService jest moliwo uycia zewntrznej implementacji menedera bezpieczestwa.
Wystarczy w tym celu zaproponowa now, alternatywn implementacj interfejsw
AuthenticationManager i RealmMapping.
Drugim, fundamentalnym zadaniem usugi JaasSecurityManagerService jest zaoferowanie implementacji typu javax.naming.spi.ObjectFactory, ktra pozwala na proste
i niewymagajce pisania kodu tworzenie na poziomie JNDI przyporzdkowa miedzy
nazw a implementacj menedera bezpieczestwa. Dziki temu, jak ju wspominalimy wczeniej, istnieje moliwo wczenia mechanizmu bezpieczestwa poprzez wskazanie nazwy JNDI konkretnej implementacji menedera bezpieczestwa, a wszystko
to na poziomie elementu security-domain deskryptora wdroenia. Jednak uycie JNDI
wymaga poprawnego przyporzdkowania nazwy do obiektu. By uproci operacj
nadawania nazwy menederowi bezpieczestwa, usuga JaasSecurityManagerService
obsuguje proces wizania tego obiektu z instancj ObjectFactory w ramach kontekstu
java:/jaas. Pozwala to stosowa konwencj, w ktrej przypisanie elementowi security-element nazwy java:/jaas/XYZ wiza si bdzie ze stworzeniem menedera bezpieczestwa w domenie XYZ. Meneder bezpieczestwa dla domeny XYZ powstanie w momencie wystpienia pierwszego odwoania do nazwy java:/jaas/XYZ, a stworzona zostanie instancja klasy okrelonej atrybutem SecurityManagerClassName. Argumentem
jej konstruktora bdzie nazwa domeny bezpieczestwa. Spjrz na fragment konfiguracji
kontenera:
<jboss>

<security-domain>java:/jaas/hades</security-domain>

</jboss>
Dowolna operacja wyszukania obiektu przyporzdkowanego nazwie java:/jaas/hades

spowoduje zwrcenie instancji menedera bezpieczestwa, ktry bdzie zwizany z domen bezpieczestwa o nazwie hades. Meneder bezpieczestwa musi implementowa
interfejsy AuthenticationManager oraz RealmMapping i jest instancj klasy wskazanej
przez atrybut SecurityManagerClassName usugi JaasSecurityManagerService.
352
Komponent JaasSecurityManagerService jest domylnie skonfigurowany w ramach standardowej dystrybucji serwera JBoss. I czsto korzystamy z tej wanie konfiguracji.
Cay czas jednak istnieje moliwo modyfikacji tych ustawie, dlatego te poniej prezentujemy list atrybutw komponentu JaasSecurityManagerService:
SecurityManagerClassName nazwa klasy bdcej implementacj menedera
bezpieczestwa. Klasa ta musi obsugiwa interfejsy org.jboss.security.
AuthenticationManager oraz org.jboss.security.RealmMapping. Gdy nie
zdefiniujemy wartoci tego atrybutu, domylnie uyta zostanie bazujca

na JAAS klasa org.jboss.security.plugins.JaasSecurityManager.
CallbackHandlerClassName nazwa klasy implementujcej interfejs
javax.security.auth.callback.CallbackHandler, ktra uywana bdzie
przez obiekt JaasSecurityManager. Domylnie uywan klas (czyli
org.jboss.security.auth.callback.SecurityAssociationHandler) moemy
zamieni, jeli nie w peni odpowiada naszym potrzebom. Przypadki takie

zdarzaj si jednak stosunkowo rzadko i wymagaj sporej wiedzy oraz
dowiadczenia.
SecurityProxyFactoryClassName nazwa klasy implementujcej interfejs
org.jboss.security.SecurityProxyFactory. Brak definicji atrybutu
oznacza, e domylnie uyta bdzie klasa org.jboss.security.
SubjectSecurityProxyFactory.
AuthenticationCacheJndiName lokalizacja regu bufora przechowujcego
dane uwierzytelniajce. Warto t traktujemy jako nazw obiektu typu

ObjectFactory, ktry zwraca instancje typu CachePolicy, z ktrych kada
przypada jednej domenie bezpieczestwa. W czasie wyszukiwania obiektu

CechePolicy do wartoci atrybutu dodawana jest nazwa domeny bezpieczestwa.
Jeli jednak operacja wykonana w taki sposb zawiedzie, to warto atrybutu
traktowana jest jako lokalizacja pojedynczego obiektu CachePolicy uywanego
przez wszystkie domeny. Domylnie przyjmuje si, e dane znajdujce si
w buforze wane s tylko przez pewien czas.
DefaultCacheTimeout czas przechowywania danych w buforze, wyraony
w sekundach. Domyln wartoci jest 1800 (30 minut). Warto podana

w tym miejscu zaley od dwch czynnikw: czstotliwoci operacji
uwierzytelniania oraz tego, jak dugo trwa moe okres braku synchronizacji
danych uwierzytelniajcych. Jeli chcemy zrezygnowa z mechanizmu
buforowania tych danych, naley wstawi warto 0. Wwczas kompletna
operacja weryfikacji bdzie miaa miejsce przy kadym daniu. Warto
atrybutu nie bdzie brana pod uwag, jeli zmienimy ustawienia domylne
AuthenticationCacheJndiName.
DefaultCacheResolution warto atrybutu okrela odstp czasu mwicy
o tym, jak czsto bufor danych uwierzytelniajcych ma by odwieany.

Warto ta powinna by mniejsza od wartoci atrybutu DefaultCacheTimeout,
inaczej pojcie okresu wanoci nie bdzie precyzyjne. Domyln wartoci
jest 60 (1 minuta). Atrybut nie bdzie brany pod uwag, jeli zmienimy
ustawienia domylne AuthenticationCacheJndiName.
DefaultUnauthenticatedPrincipal tosamo reprezentujca uytkownikw
nieuwierzytelnionych. Atrybut ten pozwala przydzieli im domylne prawa.
353
JaasSecurityManagerService oferuje take zbir przydatnych operacji. Wrd nich znajdziemy funkcj pozwalajc wyzerowa bufor danych uwierzytelniajcych w czasie
dziaania aplikacji oraz funkcj zwracajc list uytkownikw, ktrych dane znajduj
si w buforze. Istnieje te moliwo wywoania dowolnej metody zdefiniowanej w ramach interfejsu menedera bezpieczestwa.
Oprnienie bufora zwizanego z okrelon domen bezpieczestwa wie si ze skasowaniem wszystkich danych uwierzytelniajcych przechowywanych w pamici. Operacja taka moe by potrzebna na przykad w chwili, gdy zmienilimy pewne ustawienia
zwizane z bezpieczestwem i chcemy, by zaczy one obowizywa natychmiast.
W takich wanie przypadkach moemy wywoa metod o nastpujcej sygnaturze:
public void flushAuthenticationCache(String securityDomain). Poniej prezentujemy fragment kodu, w ktrym korzystamy z tej operacji:
MBeanServer server = ...;
String jaasMgrName = "jboss.security:service=JaasSecurityManager";
ObjectName jaasMgr = new ObjectName(jaasMgrName);
Object[] params = {domainName};
String[] signature = {"java.lang.String"};
server.invoke(jaasMgr, "flushAuthenticationCache", params, signature);
Pobranie listy aktywnych uytkownikw pozwala stworzy migawk, ktra zawieraa

bdzie list obiektw Principal znajdujcych si w danej chwili w buforze danych uwierzytelniajcych. Sygnatura tej metody jest nastpujca: public List getAuthenticationCachePrincipals(String securityDomain). A oto przykad jej wywoania:
MBeanServer server = ...;
String jaasMgrName = "jboss.security:service=JaasSecurityManager";
ObjectName jaasMgr = new ObjectName(jaasMgrName);
Object[] params = {domainName};
String[] signature = {"java.lang.String"};
List users = (List) server.invoke(jaasMgr, "getAuthenticationCachePrincipals",
params, signature);
A oto lista kilku kolejnych metod, ktre oferuje nam meneder bezpieczestwa:
public boolean isValid(String securityDomain, Principal principal, Object credential);
public Principal getPrincipal(String securityDomain, Principal principal);
public boolean doesUserHaveRole(String securityDomain, Principal principal,
Object credential, Set roles);
public Set getUserRoles(String securityDomain, Principal principal, Object credential);
S to metody odpowiadajce metodom zdefiniowanym w ramach interfejsw AuthenticationManager i RealmMapping i dotycz domeny bezpieczestwa okrelonej wartoci
parametru securityDomain.
Komponent JaasSecurityDomain
Komponent org.jboss.security.plugins.JaasSecurityDomain stanowi rozszerzon
wersj JaasSecurityManager, ktr uzupeniono o obsug magazynu kluczy, zgodn
z JSSE fabryk KeyManagerFactory, fabryk TrustManagerFactory obsugujc protok SSL oraz inne funkcje zwizane z szyfrowaniem danych. Pojawiy si te nowe
atrybuty pozwalajce konfigurowa usug JaasSecurityDomain:
354

KeyStoreType typ implementacji obiektu KeyStore. Argument
odpowiada wartoci przekazywanej w wywoaniu metody fabrykujcej

java.security.KeyStore.getInstance(String type). Wartoci domyln
jest JKS.
KeyStoreURL URL okrelajcy lokalizacj bazy danych obiektu KeyStore.
Suy do tworzenia strumienia InputStream inicjalizujcego magazyn kluczy
KeyStore. Jeli acuch bdcy wartoci atrybutu nie jest poprawnym URL-em,
wwczas traktujemy go jak nazw pliku.

KeyStorePass haso bazy danych obiektu KeyStore. Atrybut KeyStorePass
jest uywany rwnie w kombinacji z atrybutami Salt i IterationCount
do utworzenia klucza PBE (ang. Password Based Encryption) uywanego

podczas operacji kodowania i dekodowania. Atrybut KeyStorePass wystpuje
w jednym z nastpujcych formatw:
Haso magazynu danych wyraone w postaci zwykego tekstu warto

toCharArray() acucha znakw uywana bez adnych dodatkowych
manipulacji.
Polecenie, po wywoaniu ktrego otrzymamy haso w postaci tekstu

w tym przypadku mamy do czynienia z formatem {EXT}..., gdzie ...
jest poleceniem, ktre zostanie przekazane do metody Runtime.exec(String)
i wywoa specyficzn dla danej platformy komend systemu operacyjnego.
Pierwszy wiersz zwrcony przez wywoane polecenie traktowany jest
jako haso.
Klasa zwracajca haso w postaci tekstu warto argumentu ma format

{CLASS}classname[:ctorarg], gdzie [:ctorarg] to opcjonalny acuch,
ktry bdzie argumentem konstruktora tworzcego instancj klasy classname.
Haso zostanie przekazane za pomoc wywoania metody toCharArray(),
jeli taka metoda zostanie znaleziona. W przeciwnym przypadku korzystamy
z metody toString().
Salt warto domieszki PBEParameterSpec.

IterationCount ilo iteracji w czasie generacji klucza PBEParameterSpec.
TrustStoreType typ implementacji obiektu TrustStore. Argument
odpowiada wartoci przekazywanej w wywoaniu metody fabrykujcej

java.security.KeyStore.getInstance(String type). Wartoci domyln
jest JKS.
TrustStoreURL URL okrelajcy lokalizacj bazy danych obiektu TrustStore.
Suy do tworzenia strumienia InputStream inicjalizujcego magazyn kluczy
KeyStore. Jeli acuch bdcy wartoci atrybutu nie jest poprawnym URL-em,
wwczas traktujemy go jak nazw pliku.

TrustStorePass haso bazy danych obiektu TrustStore. Warto atrybutu
jest po prostu hasem, nie wystpuj tutaj takie opcje jak w przypadku atrybutu
KeyStorePass.
355
ManagerServiceName nazwa obiektu JMX (typu ObjectName) usugi MBean

menedera bezpieczestwa. W ten sposb komponent JaasSecurityDomain
rejestrowany jest jako meneder bezpieczestwa, a odpowiada mu bdzie

nazwa java:/jaas/<domain>, gdzie <domain> to nazwa, ktra przekazywana
jest konstruktorowi obiektu MBean. Warto domylna to jboss.security:
service=JaasSecurityManager.
Komponent adujcy plik XML

z konfiguracj logowania
XMLLoginConfig to usuga, ktra aduje standardow konfiguracj aplikacji JAAS z lokalnego pliku konfiguracyjnego. Komponent konfigurujemy za pomoc nastpujcych
atrybutw:
ConfigURL atrybut okrela URL wskazujcy na plik XML z konfiguracj
logowania, ktry adowany jest podczas uruchamiania. Wartoci atrybutu

powinien by acuch bdcy poprawn reprezentacj URL-a.
ConfigResource atrybut wskazuje nazw zasobu zawierajcego plik XML
z konfiguracj logowania. Nazwa ta traktowana jest jako cieka dostpu

w ramach lokalizowanego URL-a, uywamy przy tym zwizanego
kontekstowego classloadera wtku
ValidateDTD warto logiczna mwica o tym, czy zawarto pliku
konfiguracyjnego XML bdzie weryfikowana przy uyciu DTD. Wartoci

domyln jest true.
Struktura pliku konfiguracyjnego XML powinna odpowiada schematowi DTD pokazanemu na rysunku 8.13. Definicj DTD znajdziemy w pliku docs\dtd\security_
config.dtd.
Rysunek 8.13.
Struktura DTD
XMLLoginConfig
Atrybut name elementu application-policy to nazwa konfiguracji logowania. Odpowiada ona wartoci elementu security-domain deskryptorw jboss.xml i jboss-web.xml
chodzi o warto, ktra poprzedzona jest prefiksem java:/jaas/. Atrybut code
elementu login-module wskazuje nazw klasy implementujcej modu logowania. Atrybut flag steruje oglnym zachowaniem stosu uwierzytelniania. Oto moliwe jego wartoci wraz z krtk charakterystyk:
356

required wymagany, by operacja realizowana za pomoc moduu
LoginModule si powioda. Niezalenie jednak od tego, czy zakoczy si ona
sukcesem czy te nie, w dalszym cigu bd wywoywane dalsze, znajdujce

si na licie, moduy logowania.
requisite wymagany, by operacja realizowana za pomoc moduu
LoginModule si powioda. Jeli zakoczy si sukcesem, proces uwierzytelnienia
bdzie kontynuowany zgodnie z list zawierajc obiekty LoginModule.
W przeciwnym natomiast przypadku sterowanie wraca natychmiast do aplikacji

(pozostae obiekty LoginModule znajdujce si na licie s pomijane).
sufficient niewymagamy, by operacja realizowana za pomoc moduu
LoginModule zakoczya si sukcesem. Jeli tak si jednak stanie, sterowanie
wraca natychmiast do aplikacji (pozostae obiekty LoginModule znajdujce si
na licie s pomijane). W przeciwnym razie proces uwierzytelniania za pomoc

moduw bdcych na licie jest kontynuowany.
optional niewymagamy, by operacja realizowana za pomoc moduu
LoginModule zakoczya si sukcesem. Niezalenie od wyniku tej operacji
proces uwierzytelnienia bdzie kontynuowany zgodnie z list moduw

LoginModule.
Element login-module moe posiada zero lub wicej elementw podrzdnych module-option. Kady z nich jest par nazwa/warto, korzystamy z nich podczas inicjalizowania moduu logowania. Nazw opcji jest warto atrybutu name, natomiast wartoci
opcji jest warto samego elementu. Przykad konfiguracji logowania pokazany jest
na listingu 8.10.
Listing 8.10. Przykadowa konfiguracja moduu logowania uywana przez komponent XMLLoginConfig
<policy>
<application-policy name="srp-test">
<authentication>
<login-module code="org.jboss.security.srp.jaas.SRPCacheLoginModule"
flag="required">
<module-option name="cacheJndiName">
srp-test/AuthenticationCache
</module-option>
</login-module>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag="required">
<module-option name="password-stacking">useFirstPass</module-option>
</login-module>
</authentication>
</application-policy>
</policy>
Opisywany komponent MBean oferuje rwnie dostp do operacji, ktre pozwalaj

modyfikowa konfiguracj logowania w czasie dziaania aplikacji. Zauwa jednak,
e dowolna operacja prbujca dokona zmiany konfiguracji wymaga prawa javax.
security.auth.AuthPermission("refreshLoginConfiguration"). Przykad org.jboss.
chap8.service.SecurityConfig demonstruje, w jaki sposb moemy dynamicznie wpywa na konfiguracj obsugi bezpieczestwa. Oto lista metod:
357
void addAppConfig(String appName, AppConfigurationEntry[] entries)
metoda dodaje do biecej konfiguracji stos moduw logowania, ktremu

nadana zostanie nazwa appName. Jeli z nazw t wie si ju jaka konfiguracja,
to zostanie ona usunita.
void removeAppConfig(String appName) w ten sposb usuwamy konfiguracj
moduw logowania zarejestrowan pod podan nazw.

String[] loadConfig(URL configURL) throws Exception metoda pozwala
zaadowa jedn lub wicej konfiguracji logowania z lokalizacji okrelonej

przez URL, ktry wskazuje na plik XML bd wychodzcy ju z uycia plik
konfiguracyjny w formacie zaproponowanym przez firm Sun. Warto wiedzie,
e dodane bd albo wszystkie konfiguracje logowania, albo adna z nich.
Zwracan wartoci jest tablica zawierajca nazwy dodanych konfiguracji.
void removeConfigs(String[] appNames) metoda usuwa konfiguracje
logowania o nazwach wymienionych w tabeli appNames.
String displayAppConfig(String appName) operacja wywietla informacj
na temat konfiguracji o podanej nazwie, jeli oczywicie taka istnieje.
Komponent zarzdzajcy konfiguracj logowania

Za instalacj specjalizowanej klasy javax.security.auth.login.Configuration odpowiada usuga MBean o nazwie org.jboss.security.plugins.SecurityConfig. Posiada
ona tylko jeden atrybut, ktry wolno nam konfigurowa:
LoginConfig wartoci atrybutu jest nazwa JMX (typu ObjectName)
komponentu MBean, ktry obsuguje domyln konfiguracj logowania

JAAS. W chwili, gdy dziaanie rozpoczyna obiekt SecurityConfig, wskazany
za pomoc opisywanego atrybutu komponent MBean proszony jest o zwrcenie
instancji typu javax.security.auth.login.Configuration, a suy do tego
metoda getConfiguration(Configuration currentConfig). Gdy nie podamy
wartoci atrybutu LoginConfig, uyta zostanie domylna implementacja
interfejsu Configuration firmy Sun, jej opis znajduje si w dokumentacji
JavaDoc.
Opisywana usuga, poza opcj pozwalajc na doczanie specjalizowanej implementacji konfiguracji logowania, oferuje nam rwnie moliwo czenia konfiguracji
w stos. Dziki temu wolno nam dany obiekt konfiguracji odoy na stos, a nastpnie
go stamtd pobra. W ten sposb do domylnej instalacji serwera JBoss moemy doczy wasne moduy konfiguracji logowania. Wstawienie nowej konfiguracji na stos
odbywa si za pomoc wywoania nastpujcej metody:
public void pushLoginConfig(String objectName)
throws JMException,
MalformedObjectNameException;
Parametr objectName wskazuje odpowiedni usug MBean na tej samej zasadzie jak
atrybut LoginConfig. Do usunicia biecej konfiguracji suy metoda:
public void popLoginConfig() throws JMException;
358
Uywanie i tworzenie moduw logowania JBossSX

Implementacja JaasSecurityManager pozwala na dowoln modyfikacj mechanizmu
uwierzytelniania, a wszystko to za spraw moduw logowania JAAS. Now, wasn
implementacj uwierzytelniania definiujemy za pomoc odpowiedniej konfiguracji, ktra
odpowiada nazwie domeny bezpieczestwa chronicej nasze komponenty aplikacji J2EE.
Podsystem JBossSX zawiera kilka predefiniowanych moduw logowania, ktre
nadaj si do integracji ze standardow infrastruktur bezpieczestwa i obsuguj takie interfejsy jak LDAP lub JDBC. JBossSX oferuje take standardow implementacj klas, ktre pomog nam wykorzysta wzorzec opisany w dalszej czci rozdziau,
w punkcie Pisanie niestandardowych moduw logowania. W ten sposb w prosty sposb dokonamy integracji wasnego protokou, jeli adne z gotowych rozwiza nie spenia naszych wymaga. Niniejszy punkt rozpoczynamy od opisu gotowych, dostpnych
moduw logowania i sposobu ich konfiguracji. Nastpnie przechodzimy do dyskusji na
temat tworzenia wasnej implementacji interfejsu LoginModule i jej integracji w serwerem JBoss.
org.jboss.security.auth.spi.IdentityLoginModule
IdentityLoginModule jest prostym moduem logowania, ktry czy tosamo okrelon w opcjach z dowolnym podmiotem uwierzytelnionym w ramach moduu. Tworzona jest instancja SimplePrincipal, ktra posuguje si nazw okrelon przez parametr principal. Oczywicie opisywane rozwizanie nie nadaje si do zastosowania
w wymagajcym wysokiego stopnia bezpieczestwa rodowisku produkcyjnym, moemy jednak wykorzysta je w czasie tworzenia i testowania aplikacji, gdy chcemy
sprawdzi zabezpieczenia zwizane z okrelon tosamoci i przypisanymi jej rolami.
Oto lista opcji, za pomoc ktrych konfigurujemy opisywany modu:

principal nazwa uywana przez SimplePrincipal, za pomoc ktrej
uwierzytelniani s wszyscy uytkownicy. Jeli nie zdefiniujemy tego atrybutu,

domylnie przyjmuje si warto guest.
roles nazwy rl, ktre przypisane bd tosamoci uytkownika. Wartoci
parametru jest lista rl oddzielonych przecinkami.

password-stacking jeli opcji przypiszemy warto useFirstPass, modu
bdzie w pierwszej kolejnoci szuka wsplnej nazwy uytkownika, ktr

powinna wskazywa waciwo javax.security.auth.login.name.
Jeli zostanie ona znaleziona, bdzie traktowana jako nazwa tosamoci.
W przeciwnym razie nazwa tosamoci ustalona przez modu logowania
zostanie przypisana waciwoci javax.security.auth.login.name.
Poniej prezentujemy przykad konfiguracji XMLLoginConfig. Na jej podstawie wszystkim uytkownikom przypisana zostanie tosamo jduke, z ktr wi si role TheDuke
oraz AnimatedCharacter:
359
<policy>
<application-policy name="testIdentity">
<authentication>
<login-module code="org.jboss.security.auth.spi.IdentityLoginModule"
flag="required">
<module-option name="principal">jduke</module-option>
<module-option name="roles">TheDuke,AnimatedCharater</module-option>
</login-module>
</authentication>
</policy>
org.jboss.security.auth.spi.UsersRolesLoginModule
UsersRolesLoginModule to nieskomplikowany modu logowania obsugujcy wielu uytkownikw i wiele rl. Dane te znajduj si w plikach waciwoci Javy. Hasa przypisane poszczeglnym uytkownikom znajduj si w pliku o nazwie users.properties,
natomiast ich role zdefiniowane s w pliku roles.properties. Zawarto obu plikw adowana jest w czasie inicjalizacji, w ramach metody initialize wywoywanej przez
kontekstowego classloadera wtku. Oznacza to, e wymienione pliki mog by umieszczone w archiwum JAR wraz z aplikacj J2EE, w katalogu konfiguracyjnym JBoss,
bd te w dowolnym innym katalogu w ramach serwera lub cieki poszukiwania.
Gwnym zadaniem moduu jest umoliwienie atwego testowania bezpieczestwa aplikacji w sytuacji, w ktrej istnieje wielu zdefiniowanych uytkownikw i wiele rl.
Wszystko to za pomoc plikw waciwoci doczonych do aplikacji.
W pliku users.propeties kademu uytkownikowi odpowiada osobna linia, w ktrej

mieci si nazwa uytkownika i haso (w formacie uytkownik=haso):
uytkownik1=haso1
uytkownik2=haso2
...
Kolejne wiersze pliku roles.properties przyjmuj nastpujc posta: uytkownik=

role1,rola2,...;opcjonalnie moemy poda nazw grupy. Oto przykad:
uytkownik1=rola1,rola2,...
uytkownik1.Grupa1=rola3,rola4,...
uytkownik2=rola1,rola3,...
Nazwa w formacie uytkownik.XXX oznacza, e role przypisujemy okrelonej grupie rl,

nazw grupy jest w tym przypadku XXX. A zapis uytkownik=... jest skrcon form
zapisu uytkownik.Role, gdzie Role to standardowa nazwa grupy, ktrej spodziewa si
JaasSecurityManager i ktra posiada przypisane uprawnienia.
Dwie ponisze definicje s jednoznaczne:
jduke=TheDuke,AnimatedCharacter
jduke.Roles=TheDuke,AnimatedCharacter
360
Opisywany modu logowania konfigurowa moemy za pomoc nastpujcych parametrw:

unauthenticatedIdentity parametr ten pozwala zdefiniowa tosamo,
ktra przypisana zostanie do da nieposiadajcych adnych informacji

uwierzytelniajcych. Za pomoc tej opcji moemy zezwoli niezabezpieczonym
serwletom na wywoywanie tych metod komponentw EJB, ktre nie
wymagaj okrelonej roli. Podana w opisywany sposb tosamo nie posiada
bowiem adnych przypisanych rl, tak wic pozwala wycznie na dostp
do niezabezpieczonych komponentw EJB bd metod obiektw EJB,
dla ktrych nie zdefiniowano regu bezpieczestwa.
password-stacking jeli opcji przypiszemy warto useFirstPass,
modu bdzie w pierwszej kolejnoci szuka wsplnej nazwy uytkownika

i jego hasa, na ktre powinny wskazywa odpowiednio waciwoci
javax.security.auth.login.name oraz javax.security.auth.login.password.
Jeli zostan one znalezione, bd traktowane jako nazwa tosamoci
i odpowiadajce jej haso. W przeciwnym razie nazwa tosamoci i haso
ustalone przez modu logowania zostan przypisane waciwociom
javax.security.auth.login.name oraz javax.security.auth.login.password.
hashAlgorithm opcja pozwala wskaza algorytm java.security.MessageDigest,
ktry suy bdzie do haszowania hase. Poniewa nie jest przewidziana adna
warto domylna, wczenie haszowania wie si z koniecznoci ustalenia
wartoci parametru. Gdy parametr hashAlgorithm jest ustalony, haso w postaci
otwartego tekstu otrzymane za pomoc metody callbackHandler jest haszowane
przed dalszym przekazaniem go w roli argumentu inputPassword metody
UsernamePasswordLoginModule.validatePassword. Warto expectedPassword,
znajdujca si w pliku waciwoci users.properties, musi by haszowana
w ten sam sposb.
hashEncoding format haszowanego hasa. Parametr moe by jedn
z nastpujcych wartoci: base64 lub hex. Warto domylna to base64.
hashCharset opcja okrela sposb kodowania hasa z postaci tekstowej
do tablicy bajtw. Wartoci domyln s ustawienia systemowe.

userProperties opcja pozwala wskaza inny plik waciwoci zawierajcy
przyporzdkowanie nazw i hase uytkownikw. Przypominamy, e domylnie

jest to plik users.properties.
rolesProperties opcja pozwala wskaza inny plik waciwoci zawierajcy
przyporzdkowanie nazw i rl. Domylnie jest to plik roles.properties.

Poniej prezentujemy przykad konfiguracji XMLLoginConfig, na podstawie ktrej nieuwierzytelnionym uytkownikom przypisywana jest tosamo o nazwie nobody, a hasa w postaci haszowanej za pomoc algorytmu MD5 i w formacie base64 znajduj si
w pliku o niestandardowej nazwie usersb64.properties:
361
<policy>
<application-policy name="testUsersRoles">
<authentication>
flag="required">
<module-option name="usersProperties">usersb64.properties</moduleoption>
<module-option name="hashAlgorithm">MD5</module-option>
<module-option name="hashEncoding">base64</module-option>
<module-option name="unauthenticatedIdentity">nobody</module-option>
</login-module>
</authentication>
</policy>
org.jboss.security.auth.spi.LdapLoginModule
LdapLoginModule to implementacja moduu logowania, ktra w czasie uwierzytelnia-
nia klienta uywa serwera LDAP. Korzystamy w tym przypadku z loginu JNDI oraz
odpowiednich ustawie konfiguracyjnych moduu. Moduem LdapLoginModule naley
posugiwa si wwczas, gdy dane uytkownika i dotyczce go informacje uwierzytelniajce s przechowywane na serwerze LDAP, a dostp do niego zapewnia okrelony
dostawca JNDI.
Informacje dotyczce sposobu czenia si z serwerem LDAP zawarte s w opcjach
konfiguracyjnych i su do prawidowego stworzenia kontekstu pocztkowego JNDI.
Poniej widzimy list parametrw dotyczcych czenia z LDAP za pomoc JNDI:
java.naming.factory.initial nazwa klasy bdcej implementacj interfejsu
InitialContextFactory. Domylnie jest to dostawca LDAP firmy Sun, klasa
com.sun.jndi.ldap.LdapCtxFactory.
java.naming.provider.url URL serwera LDAP.
java.naming.security.authentication poziom okrelajcy stopie
bezpieczestwa. Wartoci domyln jest simple.
java.naming.security.protocol parametr wskazuje na protok stosowany
przy bezpiecznym dostpie, np. ssl.
java.naming.security.principal tosamo uwierzytelniajca klienta
odwoujcego si do usugi. Parametr ten opiszemy dokadnie ju za chwil.

java.naming.security.credentials warto tego parametru zaley
od wariantu uwierzytelniania. Moe to by haszowane haso, haso w postaci

otwartego tekstu, klucz, certyfikat itp.
A oto pozostae parametry konfiguracyjne moduu logowania:
principalDNPrefix opcja okrela prefiks dodawany do nazwy uytkownika
w celu stworzenia rozrnialnej nazwy. Wicej szczegw znajduje si w opisie

kolejnej opcji.
362

principalDNSuffix opcja okrela warto dodawan na kocu nazwy
uytkownika. Z opcji tej korzystamy w przypadkach, gdy nie chcemy

zmusza uytkownika do wprowadzania penej, rozrnialnej nazwy. Tak
wic ostateczna warto userDN wyznaczona jest na podstawie nastpujcego
wzoru: principalDNPrefix + <nazwa uytkownika> + principalDNSuffix.
useObjectCredential parametr przyjmuje warto true lub false. Uycie
pierwszej z tych wartoci wskazuje, e dane uwierzytelniajce bd przekazane

w postaci instancji typu Object za pomoc typu org.jboss.security.auth.
callback.ObjectCallback. W drugim przypadku bdzie to haso w postaci
tablicy typu char[] uzyskane za pomoc JAAS PasswordCallback. Istnienie
parametru pozwala na przesyanie danych do serwera LDAP w formie innej
ni char[].
rolesCtxDN opcja okrela sta nazw rozrnialn odpowiadajc
kontekstowi, w ramach ktrego szukamy rl uytkownika.

userRolesCtxDNAttributeName ten parametr okrela nazw atrybutu obiektu
uytkownika zawierajcego rozrnialn nazw kontekstu, w jakim naley

poszukiwa rl uytkownika. Rni si on od parametru rolesCtx tym,
i kontekst, jaki naley przeszukiwa moe by inny dla kadego uytkownika.
roleAttributreID ten parametr okrela nazw atrybutu zawierajcego role
uytkownikw. Jeli nie zostanie on okrelony jawnie, to przyjmie domyln

warto roles.
roleAttributeIsDN ten parametr wskazuje flag okrelajc, czy parametr
roleAttributeID zawiera w peni rozrnialn nazw obiektu roli czy te
nazw roli. Jeli przyjmie on warto false, to nazwa roli zostanie odczytana
z wartoci parametru roleAttributeID. Z kolei, jeli atrybut ten bdzie mia
warto true, to bdzie to oznacza, i atrybut roli reprezentuje rozrnialn
nazw obiektu roli. Nazw roli jest warto atrybutu roleNameAttributeId
nazwy kontekstu okrelonej przez rozrnialn nazw zapisan w atrybucie

roleAttributeId. W niektrych schematach katalogw (na przykad, w Active
Dirctory firmy Microsoft) atrybuty roli przechowywane jako w peni rozrnialne
nazwy obiektw rl, a nie jako zwyczajne nazwy. W takich przypadkach
waciwo roleAttributeIsDN powinna przyj warto true. Jej domyln
wartoci jest false.
roleNameAttributeID ta opcja okrela nazw atrybutu kontekstu
wskazywanego przez rozrnialn nazw zapisan w atrybucie roleCtxDN
zawierajcego nazw roli. Jeli atrybut roleAttributeIsDN przyjmie warto
true, to atrybutu roleNameAttributeID mona uy do odszukania atrybutu
name obiektu. Jego domyln wartoci jest group.
uidAttributeID ta opcja okrela nazw atrybutu obiektu, ktry zawiera
role odpowiadajce identyfikatorowi uytkownika. Suy ona od odnajdywania

rl uytkownika. W przypadku gdy opcja ta nie zostanie jawnie podana,
to przyjmuje warto domyln uid.
363
matchOnUserDN ta opcja jest flag logiczn (przyjmujc wartoci true

lub false) okrelajc, czy podczas poszukiwania rl uytkownikw naley
uwzgldnia ich w peni rozrnialne nazwy. Jeli atrybut ten przyjmie

warto false, to z wartoci atrybutu uidAttributeName bdzie porwnywana
nazwa uytkownika. W przeciwnym razie, kiedy atrybut przyjmie warto
true, podczas porwnywania bdzie uywana pena warto userDN.
unauthenticatedIdentity ta opcja okrela gwn nazw, jak naley
przypisa do dania, ktre nie zawiera adnych informacji uwierzytelniajcych.

Jej dziaanie jest dziedziczone po klasie bazowej UserPasswordLoginModule.
password-stacking kiedy tej opcji zostanie przypisana warto useFirstPass,
to modu logowania w pierwszej kolejnoci bdzie poszukiwa nazwy

uytkownika oraz jego hasa we waciwociach o nazwach javax.security.
auth.login.name oraz javax.security.auth.login.password przechowywanych
we wsplnej mapie stanu moduu logowania. W razie ich odnalezienia, nazwy
te zostan zastosowane jako nazwa tosamoci oraz jej haso. W przeciwnym
razie nazwa tosamoci oraz jej haso zostan okrelone przez dany modu
logowania i zapisane odpowiednio we waciwociach java.security.auth.
login.name oraz javax.security.auth.login.password.
allowEmptyPasswords ta opcja okrela flag informujc, czy puste hasa
(czyli hasa o zerowej dugoci) naley przekazywa do serwera LDAP.

Niektre serwery LDAP traktuj takie hasa jak prb logowania anonimowego,
co nie zawsze jest podane. Przypisanie tej opcji wartoci false sprawia,
e wszelkie prby logowania z wykorzystaniem hasa pustego bd odrzucane;
z kolei, zastosowanie wartoci true spowoduje, e serwer LDAP bdzie
weryfikowa puste hasa. Domyln wartoci tej opcji jest true.
Uwierzytelnianie uytkownika odbywa si poprzez nawizanie poczenia z serwerem LDAP zgodnie z informacjami konfiguracyjnymi moduu logowania. Nawizanie
poczenia polega na utworzeniu obiektu InitialLdapContext, ktrego otoczenie jest
inicjowane waciwociami LDAP JDNI opisanymi we wczeniejszej czci tego rozdziau. We waciwoci Context.SECURITY_PRINCIPAL zapisywana jest rozrnialna
nazwa uytkownika, okrelana przy wykorzystaniu metody zwrotnej, opcji principalDNPrefix, principalDNSuffix. Z kolei waciwoci Context.SECURITY_CREDENTIALS, w zalenoci od opcji useObjectCredential, przypisywany jest acuch znakw zawierajcy
haso bd te obiekt zawierajcy odpowiednie informacje.
Po poprawnym uwierzytelnieniu uytkownika, w wyniku ktrego zostanie utworzona
instancja obiektu InitialLdapContext, nastpuje sprawdzenie rl danego uytkownika. W tym celu przeszukiwana jest lokalizacja okrelona jako rolesCtxDN, przy czym
w parametrach wyszukiwania zapisywane s wartoci opcji roleAttributeName oraz
uidAttributeName. Nazwy zwrconych rl mona pobra, wywoujc metod toString
atrybutw rl zapisanych w zbiorze wynikw wyszukiwania.
364
Poniej przedstawiony zosta fragment pliku login-config.xml:

<application-policy name="testLDAP">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapLoginModule"
flag="required">
<module-option name="java.naming.factory.initial">
com.sun.jndi.ldap.LdapCtxFactory
</module-option>
<module-option name="java.naming.provider.url">
ldap://ldaphost.jboss.org:1389/
</module-option>
<module-option name="java.naming.security.authentication">
simple
</module-option>
<module-option name="principalDNPrefix">uid=</module-option>
<module-option name="principalDNSuffix">
,ou=People,dc=jboss,dc=org
</module-option>
<module-option name="rolesCtxDN">
ou=Roles,dc=jboss,dc=org
</module-option>
<module-option name="uidAttributeID">member</module-option>
<module-option name="matchOnUserDN">true</module-option>
<module-option name="roleAttributeID">cn</module-option>
<module-option name="roleAttributeIsDN">false </module-option>
</login-module>
</authentication>
Poniej przedstawiony zosta plik LDIF reprezentujcy struktur katalogu, na ktrym

operuj powysze dane:
dn: dc=jboss,dc=org
objectclass: top
objectclass: dcObject
objectclass: organization
dc: jboss
o: JBoss
dn: ou=People,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: People
dn: uid=jduke,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: uidObject
objectclass: person
uid: jduke
cn: Java Duke
sn: Duke
userPassword: theduke
dn: ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Roles
365
dn: cn=JBossAdmin,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: JBossAdmin
member: uid=jduke,ou=People,dc=jboss,dc=org
description: the JBossAdmin group
Przegldajc przedstawion we wczeniejszej czci rozdziau konfiguracj moduu

logowania testLDAP, mona zauway, i zgodnie z wartociami opcji java.naming.
factory.initial, java.naming.factory.url oraz java.naming.security zostanie wykorzystana implementacja dostawcy LDAP JNDI firmy Sun, serwer LDAP dostpny
pod adresem ldaphost.jboss.org i dziaajcy na porcie 1389, a do nawizania poczenia z serwerem LDAP zostanie uyta prosta metoda uwierzytelniania (simple).
Podczas prb nawizania poczenia z serwerem LDAP modu logowania korzysta
z w peni rozrnialnej nazwy reprezentujcej uytkownika starajcego si o uwierzytelnienie. Nazwa ta tworzona jest na podstawie opcji principalDNPrefix przekazanej w nazwie uytkownika oraz opcji principalDNSuffix opisanej we wczeniejszej
czci rozdziau. W przedstawionym przykadzie uytkownik o nazwie jduke zostay
skojarzony z wpisem uid=jduke,ou=People,dc=jboss,dc=org. Zakadamy przy tym, e
serwer LDAP przeprowadza uwierzytelnianie uytkownikw, korzystajc przy tym
z atrybutu userPassword (ktry w powyszym przykadzie ma warto theduke). W taki
sposb dziaa przewaajca wikszo serwerw LDAP, niemniej jednak, jeli uywany serwer LDAP dziaa inaczej, konieczne bdzie ustawienie opcji uwierzytelniania w odpowiedni sposb.
Po udanym uwierzytelnieniu uytkownika naley pobra role, na podstawie ktrych
zostanie przeprowadzona autoryzacja. W tym celu przeprowadzana jest analiza poddrzewa roleCtxDN w poszukiwaniu wpisw, w ktrych warto uidAttributeID odpowiada danemu uytkownikowi. Jeli opcja matchOnUserDN ma warto true, to wyszukiwanie bazuje na rozrnialnej nazwie uytkownika. W przeciwnym razie uywana
jest faktyczna, podana nazwa. W powyszym przykadzie analizowany bdzie fragment
poniej ou=Roles,dc=jboss,dc=org, a poszukiwane w nim bd wszelkie wpisy, w ktrych warto atrybutu member bdzie wynosi uid=duke,ou=People,dc=jboss,dc=org.
W tym przykadzie zwrcona zostanie warto cn=JBossAdmin we wpisie roles.
W wyniku wyszukiwania zwracany jest atrybut okrelony przez opcj roleAttributeID.
W powyszym przykadzie atrybutem tym jest cn. Poniewa wyszukiwanie zwrci
warto JBossAdmin, uytkownik jduke zostanie powizany z rol JBossAdmin.
Czsto zdarza si, e lokalny serwer LDAP udostpnia usugi zwizane z okrelaniem
tosamoci oraz uwierzytelnianiem, lecz nie jest w stanie korzysta z usug autoryzacji.
Wynika to z faktu, i role uywane w aplikacji nie zawsze dobrze odpowiadaj grupom LDAP, a administratorzy zazwyczaj nie s chtni do umieszczania na centralnych serwerach LDAP zewntrznych danych, z ktrych korzystaj aplikacje. Wanie
z tych powodw bardzo czsto moduy przeprowadzajce uwierzytelnianie w oparciu
o serwery LDAP s uywane wraz z dodatkowymi moduami logowania, takimi jak
moduy logujce wykorzystujce bazy danych, ktre s w stanie dostarcza informacji
o rolach odpowiadajcych potrzebom tworzonej aplikacji.
366
org.jboss.security.auth.spi.DatabaseServerLoginModule
DatabaseServerLoginModule jest implementacj moduu logowania wykorzystujce-
go JDBC, ktry obsuguje zarwno uwierzytelnianie, jak i przypisywanie rl. Mona

z niego korzysta, jeli informacje o nazwach uytkownikw, ich hasach oraz skojarzonych z nimi rolach s przechowywane w relacyjnej bazie danych. Modu ten wykorzystuje dwie logiczne tabele:
Tabela Principals(PrincipalID text, Password text)
Tabela Roles(PrincipalID text, Role text, RoleGroup text)
Pierwsza z tych tabel Principals kojarzy PrincipalID uytkownika z poprawnym hasem. Z kolei tabela Roles kojarzy PrincipalID uytkownika ze zbiorem rl.
Role suce do okrelania uprawnie uytkownika musz by zapisywane w wierszach, w kolumnie RoleGroup. Tabele te s logiczne w tym sensie, i istnieje moliwo
podania zapytania SQL, ktre bdzie uywane przez modu logowania. Jedyny wymg
sprowadza si do tego, by zwracany obiekt java.sql.ResultSet mia identyczn struktur jak przedstawione powyej dwie tabele: Principals oraz Roles. Rzeczywiste nazwy
tabel oraz ich kolumn nie maj tu wikszego znaczenia, gdy wyniki s odczytywane
przy wykorzystaniu indeksw kolumn, a nie ich nazw. Aby dokadniej wyjani, co to
oznacza, przeanalizujemy przykad bazy danych zawierajcej dwie tabele Principals oraz Roles o przedstawionej wczeniej strukturze. Pierwsze z przedstawionych
poniej polece SQL zapisuje w tabeli Principals wiersz danych, ktry w kolumnie
PrincipalID zawiera warto java, a w kolumnie Password warto echoman. Pozostae dwa polecenia zapisuj dwa wiersze w tabeli Roles. W pierwszym z nich w polu
PrincipalID zostaje umieszczona warto java, w polu Roles okrelajcym nazw roli
warto Echo, a w polu RoleGroup warto Roles; w drugim z rekordw w tych samych
kolumnach zostan odpowiednio zapisane wartoci: java, caller_java oraz CallerPrincipal.
INSERT INTO Principals VALUES('java', 'echoman')
INSERT INTO Roles VALUES('java', 'Echo', 'Roles')
INSERT INTO Roles VALUES('java', 'caller_java', 'CallerPrincipal')
Poniej przedstawione zostay opcje konfiguracyjne tego moduu logowania:

dsJndiName ta opcja okrela nazw JNDI rda danych (DataSource)
reprezentujcego baz danych zawierajc logiczne tabele Principals
oraz Roles. Jeli opcja ta nie zostanie jawnie okrelona, to przyjmie warto
domyln java:/DefaultDS.
principalsQuery ta opcja okrela przygotowane zapytanie SQL stanowice
odpowiednik zapytania select Password from Principals where PrincipalID=?.
To polecenie zostanie zastosowane, jeli warto opcji nie bdzie jawnie podana.
rolesQuery ta opcja okrela przygotowane zapytanie SQL stanowice
odpowiednik zapytania select Role, RoleGroup from Roles where
PrincipalID=?. To polecenie zostanie zastosowane, jeli warto opcji
nie zostanie jawnie podana.

unauthenticatedIdentity ta opcja okrela tosamo przypisywan
daniom, ktre nie zawieraj adnych informacji uwierzytelniajcych.
367
password-stacking jeli ta opcja przyjmie warto useFirstPass,
to modu logowania w pierwszej kolejnoci sprbuje odczyta ze wsplnej

mapy stanu wartoci waciwoci javax.security.auth.login.name oraz
javax.security.auth.login.password, okrelajce odpowiednio nazw
uytkownika oraz jego haso. Jeli wartoci te zostan odczytane, to modu
uyje ich podczas uwierzytelniania. W przeciwnym przypadku tosamo
oraz haso uytkownika zostan okrelone przez modu logowania i zapisane
we odpowiednio we waciwociach javax.security.auth.login.name oraz
javax.security.auth.login.password.
hashAlgorithm opcja okrela nazw algorytmu java.security.MessageDigest,
ktry zostanie uyty do haszowania hasa. Opcja ta nie ma wartoci domylnej,

zatem aby haszowanie zostao wczone, naley j jawnie poda. W przypadku
okrelenia wartoci tej opcji, zanim haso podane otwartym tekstem (zwrcone
przez metod zwrotn callbackhandler) bdzie przekazane jako argument
inputPassword do metody UsernamePasswordLoginModule.validatePassword,
zostanie ono zahaszowane. Warto expectedPassword odczytywana przez
modu logowania z bazy danych musi by zahaszowana w identyczny sposb.
hashEncoding ta opcja okrela format acucha znakw, w jakim zostanie
zapisane zahaszowane haso. Opcja ta moe przyjmowa tylko dwie wartoci:

base64 lub hex, przy czym jej domyln wartoci jest base64.
hashCharset ta opcja okrela sposb kodowania, jaki bdzie uywany
do przeksztacenia tekstowego hasa na posta tablicy bajtw. Domylnie

uywane jest domylne kodowanie uywanej platformy systemowej.
ignorePasswordCase ta opcja suy do podania wartoci flagi logicznej
okrelajcej, czy podczas sprawdzania hasa naley uwzgldnia wielko

liter. Moe ona by przydatna w przypadku kodowania zahaszowanego hasa
w sytuacjach, gdy wielko liter uzyskanego acucha znakw nie ma znaczenia.
principalClass opcja okrela nazw klasy implementujcej interfejs
Principal. Klasa ta musi udostpnia konstruktor pobierajcy jeden argument
bdcy acuchem znakw, ktry reprezentuje nazw uytkownika.

W ramach przykadu konfiguracji moduu DatabaseServerLoginModule przeanalizujmy
tabele o nastpujcej strukturze:
CREATE TABLE Users(username VARCHAR(64) PRIMARY KEY, passwd VARCHAR(64))
CREATE TABLE UserRoles(username VARCHAR(64), userRoles VARCHAR(32))
Poniej przedstawiono fragment pliku konfiguracyjnego login-config.xml, ktry operuje

na tych tabelach:
<application-policy name="testDB">
<authentication>
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule"
flag="required">
<module-option name="dsJndiName">java:/MyDatabaseDS</module-option>
<module-option name="principalsQuery">
select passwd from Users username where username=?</module-option>
368

<module-option name="rolesQuery">
select userRoles, 'Roles' from UserRoles where username=?</moduleoption>
</login-module>
</authentication>
BaseCertLoginModule
BaseCertLoginModule jest moduem, ktry przeprowadza uwierzytelnianie uytkownikw na podstawie certyfikatw X509. Zazwyczaj modu ten jest uywany przez warstw sieciow korzystajc z metody uwierzytelniania CLIENT-CERT. Modu ten suy
wycznie do uwierzytelniania, dlatego te, w celu penego zdefiniowania dostpu do
zabezpieczonego komponentu sieciowego lub komponentu EJB, naley wykorzystywa go wsplnie z innym moduem logowania, ktry bdzie w stanie pobiera informacje o rolach konieczne do autoryzacji uytkownika. Dwie klasy pochodne tego
moduu, CertRolesLoginModule oraz DatabaseCertLoginModule, rozszerzaj jego dziaanie i zapewniaj moliwo pobierania rl z waciwoci lub z bazy danych.
Do przeprowadzenia weryfikacji uytkownika modu BaseCertLoginModule musi korzysta z obiektu KeyStore. Obiekt ten jest pobierany przy uyciu implementacji interfejsu org.jboss.security.SecurityDomain. Przewanie implementacja klasy SecurityDomain jest konfigurowana przy uyciu komponentu MBean org.jboss.security.
plugins.JaasSecurityDomain, przedstawionego na poniszym przykadzie pliku jboss-serice.xml:
<mbean code="org.jboss.security.plugins.JaasSecurityDomain"
name="jboss.web:service=SecurityDomain">
<constructor>
<arg type="java.lang.String" value="jmx-console"/>
</constructor>
<attribute name="KeyStoreURL">resource:localhost.keystore</attribute>
<attribute name="KeyStorePass">unit-tests-server</attribute>
</mbean>
Powyszy fragment tworzy domen bezpieczestwa o nazwie jmx-console, ktrej klasa

implementujca interfejs SecurityDomain jest dostpna za pomoc JNDI pod nazw
java:/jaas/jmx-console, zgodn ze wzorcem nazw domen bezpieczestwa stosowanych przez JBossSX. Aby zabezpieczy aplikacj sieciow tak jak jmx-console.war
przy wykorzystaniu certyfikatw klienta oraz autoryzacji bazujcej na rolach, w pierwszej kolejnoci naleaoby zmodyfikowa plik web.xml i zadeklarowa w nim zabezpieczane zasoby, role, jakie maj do nich dostp, oraz dziedzin zabezpiecze, jakiej
naley uywa podczas uwierzytelniania i autoryzacji. Poniej przedstawiony zosta fragment pliku web.xml okrelajcy wszystkie te informacje:
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
...
369
<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>Przykadowa konfiguracja bezpieczestwa pozwalajca
uytkownikom posiadajcym rol JBossAdmin na dostp do aplikacji sieciowej
JMX console </description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>JBoss JMX Console</realm-name>
</login-config>
<security-role>
<role-name>JBossAdmin</role-name>
</security-role>
</web-app>
Nastpnie w pliku jboss-web.xml naley okreli dziedzin bezpieczestwa JBossa:

<jboss-web>
<security-domain>java:/jaas/jmx-console</security-domain>
</jboss-web>
Ostatnim krokiem jest zdefiniowanie konfiguracji moduu logowania dla okrelonej powyej domeny bezpieczestwa jmx-console. Niezbdne informacje s umieszczane
w pliku conf/login-config.xml:
<application-policy name="jmx-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.BaseCertLoginModule"
flag="required">
<module-option name="securityDomain">java:/jaas/jmx-console</module-option>
</login-module>
flag="required">
<module-option name="usersProperties">jmx-console-users.properties</
module-option>
<module-option name="rolesProperties">jmx-console-roles.properties</
module-option>
</login-module>
</authentication>
W tym przypadku modu BaseCertLoginModule jest uywany do uwierzytelniania certyfikatu uytkownika, natomiast ze wzgldu na zastosowanie opcji password-stacking=
useFirstPass modu UserRolesLoginModule jest uywany wycznie do autoryzacji.
370
Zarwno localhost.keystore, jak i jmx-console-roles.properties wymagaj wpisu,

ktry okreli odwzorowanie z tosamoci skojarzon z certyfikatem klienta. Domylnie tosamo jest tworzona przy wykorzystaniu rozrnialnej nazwy podanej w certyfikacie klienta. Przeanalizujmy nastpujcy certyfikat:
[starksm@banshee9100 conf]$ keytool -printcert -file unit-tests-client.export
Owner: CN=unit-tests-client, OU=JBoss Inc., O=JBoss Inc., ST=Washington, C=US
Issuer: CN=jboss.com, C=US, ST=Washington, L=Snoqualmie Pass, EMAILADDRESS=admin
@jboss.com, OU=QA, O=JBoss Inc.
Serial number: 100103
Valid from: Wed May 26 07:34:34 PDT 2004 until: Thu May 26 07:34:34 PDT 2005
Certificate fingerprints:
MD5: 4A:9C:2B:CD:1B:50:AA:85:DD:89:F6:1D:F5:AF:9E:AB
SHA1: DE:DE:86:59:05:6C:00:E8:CC:C0:16:D3:C2:68:BF:95:B8:83:E9:58
Na potrzeby localhost.keystore certyfikat ten powinien zosta zapisany z aliasem

o postaci CN=unit-tests-client, OU=JBoss Inc.,O=JBoss Inc., ST=Washington, C=US;
z kolei jmx-console-roles.properties take wymaga wpisu dla tego samego wpisu.
Poniewa wpis DN zawiera wiele znakw, ktre normalnie s traktowane jako separatory, zatem konieczne bdzie poprzedzenie ich znakami odwrotnego ukonika, jak
w poniszym przykadzie:
# Przykadowy plik roles.properties uywany przez modu logowania UsersRolesLoginModule
CN\=unit-tests-client,\ OU\=JBoss\ Inc.,\ O\=JBoss\ Inc.,\ ST\=Washington,\
C\=US=JBossAdmin
admin=JBossAdmin
org.jboss.security.auth.spi.RunAsLoginModule
JBoss posiada pomocniczy modu logowania o nazwie RunAsLoginModule, ktry pozwala na zastosowanie roli pomocniczej podczas trwania fazy uwierzytelniania i zaprzestanie stosowania tej roli w momencie zakoczenia uwierzytelniania (niezalenie
od jego wyniku). Modu ten zosta stworzony w celu udostpnienia roli, z jakiej mogyby korzysta inne moduy logowania, ktre podczas przeprowadzania uwierzytelniania musz mie dostp do zasobw chronionych. Na przykad z moduu RunAsLoginModule moe korzysta modu logowania korzystajcy z chronionego komponentu EJB.
Modu RunAsLogingModule musi zosta skonfigurowany przed zastosowaniem innych
moduw logowania korzystajcych z roli pomocniczej.
Jedyn opcj konfiguracyjn tego moduu jest roleName; zawiera ona nazw roli
pomocniczej, ktra bdzie uywana podczas fazy logowania. Jeli nazwa tej roli nie
zostanie jawnie podana, przyjta zostanie warto domylna nobody.
org.jboss.security.ClientLoginModule
Modu ClientLoginModule jest implementacj interfejsu LoginModule uywanego przez
klientw JBossa do okrelenia tosamoci oraz informacji uwierzytelniajcych klienta. Modu ten zapisuje we waciwoci org.jboss.security.SecurityAssociation.
principal warto typu NameCallback zwrcon przez metod callbackhandler, a we
waciwoci org.jboss.security.SecurityAssociation.credential zwrcon warto
typu PasswordCallback. Jest to jedyny dostpny mechanizm pozwalajcy klientowi na
371
okrelenie, kto odwoa si do biecego wtku. Moduu tego musz uywa zarwno
niezalene aplikacje klienckie, jak i aplikacje dziaajce w rodowisku serwera, ktre
funkcjonuj jako klienty EJB w sytuacjach, gdy rodowisko zabezpiecze nie zostao
skonfigurowane w sposb zapewniajcy moliwo niezauwaalnego korzystania
z podsystemu JBossSX. Oczywicie zawsze mona bezporednio okreli informacje
org.jboss.security.SecurityAssociation, niemniej jednak interfejs ten jest uwaany
za API wewntrzne, ktre w kadej chwili moe ulec zmianie bez wczeniejszych zapowiedzi.
Naley zauway, e ten modu logowania nie przeprowadza uwierzytelniania, a jedynie kopiuje przekazane do niego informacje dotyczce logowania do warstwy wywoa EJB serwera JBoss w celu ich pniejszego wykorzystania podczas uwierzytelniania. Jeli niezbdne jest przeprowadzenie uwierzytelniania uytkownika po stronie
klienta, to oprcz moduu ClientLoginModule naley wykorzysta take inny modu
logowania.
Poniej zostay opisane dostpne opcje konfiguracyjne tego moduu:
multi-threaded jeli tej opcji zostanie przypisana warto true,
to kady wtek logowania bdzie dysponowa wasnym obszarem sucym

do przechowywania danych o tosamoci i informacji uwierzytelniajcych.
Moliwo ta jest przydatna w rodowiskach klienckich, w ktrych, w osobnych
wtkach, s aktywne dane wielu rnych uytkownikw. Jeli opcja ta przyjmie
warto true, to kady wtek musi osobno przeprowadza logowanie.
W przeciwnym przypadku, kiedy opcja przyjmie warto false, zarwno
tosamo, jak i inne informacje uwierzytelniajce bd zmiennymi globalnymi,
dostpnymi i uywanymi przez wszystkie wtki dziaajce na danej wirtualnej
maszynie Javy. Wartoci domyln tej opcji jest false.
password-stacking jeli ta opcja przyjmie warto useFirstPass,
to modu logowania w pierwszej kolejnoci sprbuje odczyta ze wsplnej

mapy stanu wartoci waciwoci javax.security.auth.login.name oraz
javax.security.auth.login.password, okrelajce odpowiednio nazw
uytkownika oraz jego haso. W ten sposb moduy, ktre s uywane, mog
przed tym okreli poprawn nazw uytkownika oraz haso, ktre zostan
przekazane do serwera JBoss. Opcja ta jest uywana w przypadkach, gdy
chcemy przeprowadzi uwierzytelnianie aplikacji po stronie klienta, uywajc
przy tym innego moduu logowania, jak na przykad LdapLoginModule.
restore-login-identity w przypadku, gdy opcja ta przyjmie warto true,
informacje zapisane w obiekcie SecurityAssociation i przekazywane
do metody login() s zapisywane, a nastpnie odtwarzane w momencie
przerywania logowania lub wylogowywania klienta. Jeli opcja ta przyjmie

domyln warto false, przerwanie operacji logowania lub wylogowanie
klienta powoduje usunicie wszelkich informacji zapisanych w obiekcie
SecurityAssociation. Przypisanie tej opcji wartoci true jest konieczne
w przypadkach, gdy trzeba zmieni, a nastpnie przywrci oryginaln
tosamo.
372
Przedstawiony poniej fragment konfiguracji moduu ClientLoginModule przedstawia

domylny wpis konfiguracyjny skopiowany z pliku client/auth.conf, ktry mona
znale w dystrybucji serwera JBoss:
other {
1
// Put your login modules that work without jBoss here
// jBoss LoginModule
org.jboss.security.ClientLoginModule required;
2
// Put your login modules that need jBoss here

};
Pisanie niestandardowych moduw logowania

Jeli moduy logowania, w jakie domylnie wyposaony jest podsystem JBossSX, nie
s w stanie wsppracowa z uywanym systemem zabezpiecze, to mona napisa
wasne moduy implementujce wszystkie niezbdne moliwoci.
Czytelnik zapewne pamita, e klasa JaasSecurityManager przedstawiona wczeniej
w podrozdziale Architektura JBossSX oczekuje, e obiekty Subject bd wykorzystywane w cile okrelony sposb. Koniecznie naley zrozumie sposoby przechowywania informacji przez obiekty tego typu, ich cechy oraz oczekiwane sposoby ich stosowania. Wiedza ta jest konieczna do tworzenia moduw logowania, ktre bd w stanie
wsppracowa z klas JaasSecurityManager. W tej czci rozdziau zostay przedstawione wymienione wczeniej zagadnienia, a oprcz tego podano w niej informacje
o dwch abstrakcyjnych klasach bazowych implementujcych interfejs LoginModule,
ktre mog pomc w tworzeniu wasnych moduw logowania.
JBoss udostpnia sze metod sucych do pobierania informacji przechowywanych
w obiektach Subject:
java.util.Set
java.util.Set
java.util.Set
java.util.Set
java.util.Set
java.util.Set
getPrincipals(),
getPrincipals(java.lang.Class c),
getPrivateCredentials(),
getPrivateCredentials(java.lang.Class c),
getPublicCredentials(),
getPublicCredentials(java.lang.Class c).
Jeli chodzi o informacje uwierzytelniajce oraz informacje o rolach udostpniane przez

obiekty Subject, to w podsystemie JBossSX dokonano najbardziej naturalnego wyboru:
s one zwracane w formie zbioru (obiektu typu Set) przez metody getPrincipals()
oraz getPrincipals(java.lang.Class). Poniej przedstawiony zosta sposb ich wykorzystania:
Tutaj zapisz moduy logowania, ktre nie wymagaj JBossa.
Tutaj zapisz moduy logowania, ktre wymagaj JBossa.
373
Informacje o tosamoci uytkownika (nazwa uytkownika, numer PESEL,

identyfikator pracownika i tak dalej) s przechowywane w zbiorze Subject
Principals w formie obiektw typu java.security.Principal. Klasa,
ktra reprezentuje tosamo uytkownika, implementujca interfejs

java.security.Principal musi zapewnia operacje porwnania oraz
rwnoci bazujce na nazwie tosamoci uwierzytelniajcej. JBoss udostpnia
przydatn implementacj takiej klasy o nazwie org.jboss.security.
SimplePrincipal. W razie potrzeby do zbioru Subject Principals mona
dodawa inne instancje typu Principal.
Przypisane role uytkownikw take s przechowywane w zbiorze Principals,
jednak s one grupowane na podstawie nazwy roli przy wykorzystaniu

obiektw java.security.acl.Group. Interfejs Group definiuje kolekcj
obiektw Principals i (bd) Groups. Group jest interfejsem pochodnym
interfejsu java.security.Principal. Dowoln ilo rl mona przypisa
do obiektu Subject. Obecnie JBossSX uywa dwch dobrze znanych zbiorw
rl noszcych nazwy Roles oraz CallerPrincipal. Grupa Roles jest kolekcj
obiektw Principal reprezentujcych nazwane role dostpne w domenie
aplikacji, w ktrej Subject zosta uwierzytelniony. Ten zbir rl jest uywany
midzy innymi przez metod EJBContext.isCallerInRole(String), ktrej
komponenty EJB mog uywa do sprawdzenia, czy wywoujcy je klient
naley do nazwanej roli domeny aplikacji. Z tego zbioru korzystaj take
mechanizmy obiektu przechwytujcego odpowiadajcego za bezpieczestwo,
realizujce sprawdzenie uprawnie. Z kolei grupa CallerPrincipal zawiera
pojedynczy obiekt Principal przypisany uytkownikowi w domenie aplikacji.
Jest ona wykorzystywana przez metod EJBContext.getCallerPrincipal()
w celu zapewnienia domenie aplikacji moliwoci odwzorowania tosamoci
uytkownika stosowanej w rodowisku pracy na tosamo, ktra bdzie
przydatna dla samej aplikacji. Jeli obiekt Subject nie zawiera grupy
CallerPrincipal, oznacza to, e tosamo uywana w aplikacji jest taka
sama jak tosamo uywana w rodowisku pracy.
Obsuga sposobu wykorzystania obiektu Subject

W celu uproszczenia implementacji opisanego powyej sposobu wykorzystania obiektu
Subject podsystem JBossSX udostpnia dwa abstrakcyjne moduy logowania, ktre
obsuguj zapisywanie informacji w uwierzytelnionym obiekcie Subject, a jednoczenie
wymuszaj jego poprawne zastosowanie. Bardziej oglnym z nich jest klasa org.jboss.
security.auth.spi.AbstractServerLoginModule. Zapewnia ona konkretn implementacj interfejsu javax.security.auth.spi.LoginModule i udostpnia abstrakcyjne metody suce do realizacji wszystkich kluczowych operacji typowych dla infrastruktury
zabezpiecze rodowiska pracy. Poniszy fragment kodu rdowego klasy przedstawia jej kluczowe szczegy, a zamieszczone w nim komentarze opisuj przeznaczenie
poszczeglnych metod:
1: package org.jboss.security.auth.spi;
2: /**
3: * Ta klasa implementuje wsplne moliwoci funkcjonalne, ktre musz
4: * posiada dziaajce na serwerze moduy JAAS LoginModule, oraz
5: * implementuje narzucany przez JBossSX schemat wykorzystania obiektw
374

6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
*
*
*
*
Subject do przechowywania informacji o tosamoci i rolach.

Klas t mona wykorzysta do stworzenia wasnych moduw logowania
LoginModule, w ktrych zostan przesonite metody login(),
getRoleSets() oraz getIdentity().
*/
public abstract class AbstractServerLoginModule
implements javax.security.auth.spi.LoginModule
{
protected Subject subject;
protected CallbackHandler callbackHandler;
protected Map sharedState;
protected Map options;
protected Logger log;
/** Flaga okrelajca, czy naley uywa wsplnych danych
* o tosamoci */
protected boolean useFirstPass;
/**
* Flaga informujca o tym, czy faza logowania zakoczya si
* powodzeniem. Klasy pochodne przesaniajce metod login()
* musz przypisywa tej skadowej warto true, jeli logowanie
* zakoczyo si pomylnie.
*/
protected boolean loginOk;
// ...
/**
* Metoda inicjalizuje modu logowania. Zapisuje obiekt
* Subject, CallbackHandler, map sharedState oraz map
* zawierajc opcje sesji logowania. Metod t naley przesania,
* jeli klasy pochodne musz przetwarza wasne opcje sesji.
* W takim przypadku konieczne jest wywoanie tej metody w klasie
* bazowej - super.initialize(...).
*
* <p>
* W opcjach poszukiwany jest parametr <em>password-stacking</em>.
* Jeli przypisano mu warto "useFirstPass", to tosamo uywana podczas
* logowania zostanie pobrana z wartoci
* <code>javax.security.auth.login.name</code> mapy sharedState, natomiast
* informacja potwierdzajca tosamo z wartoci
* <code>javax.security.auth.login.password</code> tej samej mapy.
*
* @param subject obiekt Subject, ktry naley zaktualizowa po pomylnym
* logowaniu
* @param callbackHandler obiekt CallbackHandler, ktry zostanie uyty w celu pobrania
* informacji o tosamoci uytkownika oraz danych niezbdnych do jego uwierzytelnienia
* @param sharedState obiekt Map uywany przez wszystkie skonfigurowane moduy logowania
* @param options parametry przekazywane do moduu logowania
*/
public void initialize(Subject subject,
CallbackHandler callbackHandler,
Map sharedState,
Map options)
{
// ...
}
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102: }
375
/**
* Jeli uyto wartoci "useFirstPass", to metoda ta poszukuje w mapie
* sharedState wartoci javax.security.auth.login.name oraz
* javax.security.auth.login.password i zwraca warto true, jeli
* zostay one odnalezione. Jeli wartoci te nie istniej lub wynosz
* null, to metoda zwraca warto false.
*
* Naley zauway, e w przypadku pomylnego logowania klasy pochodne
* przesaniajce metod login() musz przypisywa skadowej loginOk
* warto true, aby w pniejszej fazie logowania w obiekcie
* Subject zostay poprawnie zapisane informacje. Ta implementacja
* przypisuje skadowej loginOk warto true, jeli metoda login() zwrci
* warto true; w przeciwnym razie skadowej loginOk przypisywana jest
* warto false.
*/
public boolean login()
throws LoginException
{
// ...
}
/**
* Ta metoda jest przesaniana przez klasy pochodne, tak by zwracaa
* obiekt Principal odpowiadajcy podstawowej tosamoci uytkownika.
*/
abstract protected Principal getIdentity();
/**
* Ta metoda, przesaniana przez klasy pochodne, zwraca obiekt Groups
* zawierajcy zbir rl przypisanych danemu uytkownikowi. W najprostszym
* przypadku klasy pochodne powinny utworzy obiekt Group skojarzony z
* nazw "Roles" i zawierajcy role przypisane danemu uytkownikowi.
* Drug powszechnie uywan grup jest "CallerPrincipal" okrelajca
* tosamo uytkownika w danej aplikacji, a nie w domenie bezpieczestwa.
*
* @return Group[] containing the sets of roles
*/
abstract protected Group[] getRoleSets() throws LoginException;
Naley zwrci uwag na zmienn loginOk. Wszystkie klasy pochodne przesaniajce

metod login() musz przypisa jej warto true w przypadku udanego logowania lub
warto false w przeciwnym razie. W przypadku, gdy warto tej zmiennej nie zostanie poprawnie okrelona, moe si okaza, e metoda commit() bd to nie zaktualizuje informacji o podmiocie (obiektu Subject), bd te zaktualizuje je w nieodpowiednim momencie. Moliwo ledzenia wynikw fazy logowania zostaa dodana
po to, by poczone w acuch moduy logowania nie musiay zgasza poprawnoci
logowania w cile okrelonej kolejnoci, aby caa operacja logowania zakoczya si
pomylnie.
Drugi z abstrakcyjnych bazowych moduw logowania nadajcych si do wykorzystania podczas tworzenia wasnych moduw nosi nazw org.jboss.security.auth.
spi.UsernamePasswordLoginModule. Modu ten wymaga, by tosamo uytkownika
bya okrelana przy uyciu jego nazwy zapisanej jako acuch znakw (String), a haso
376
potwierdzajce t tosamo byo przekazywane jako tablica znakw (char[]). Takie

rozwizanie dodatkowo upraszcza implementacj niestandardowych moduw logowania. Oprcz tego modu UserPasswordLoginModule zapewnia moliwo kojarzenia
uytkownikw anonimowych (identyfikowanych przy uyciu pustej nazwy oraz hasa)
z tosamoci, ktra nie posiada adnych rl. Poniszy fragment kodu rdowego
klasy przedstawia jej kluczowe szczegy, a zamieszczone w nim komentarze opisuj
przeznaczenie poszczeglnych metod.
1: package org.jboss.security.auth.spi;
2: /**
3: * Abstrakcyjna klasa pochodna klasy AbstractServerLoginModule wymagajca,
4: * by tosamo bya okrelana poprzez podanie nazwy uytkownika zapisanej
5: * jako acuch znakw, a informacje uwierzytelniajce poprzez podanie hasa
6: * zapisanego jako tablica znakw. Klasy pochodne musz przesania metody
7: * getUsersPassword() oraz getUsersRoles(), ktre bd odpowiednio zwraca
8: * oczekiwan nazw uytkownika oraz haso.
9: */
10: public abstract class UsernamePasswordLoginModule
11:
extends AbstractServerLoginModule
12: {
13:
/** Tosamo uywana podczas logowania */
14:
private Principal identity;
15:
/** Potwierdzenie tej tosamoci */
16:
private char[] credential;
17:
/** Tosamo, jakiej naley uy w przypadku przekazania
18:
* pustej nazwy uytkownika i hasa */
19:
private Principal unauthenticatedIdentity;
20:
21:
/**
22:
* Algorytm uywany do zahaszowania hasa; jeli zostania uyta warto
23:
* null, to hasa bd przekazywane w niezmienionej postaci */
24:
private String hashAlgorithm = null;
25:
26:
/**
27:
* Nazwa zbioru znakw (lub sposobu kodowania), jaki naley wykorzysta
28:
* podczas konwersji hasa podanego w formie acucha znakw do postaci
29:
* tablicy bajtw. Domylnie stosowane jest domylne kodowanie uywane
30:
* przez platform systemow.
31:
*/
32:
private String hashCharset = null;
33:
34:
/** Format kodowania acuchw znakw, jaki naley zastosowa.
35:
* Domylnie jest to base64. */
36:
private String hashEncoding = null;
37:
38:
// ...
39:
40:
/**
41:
* Ta metoda przesania metod klasy bazowej poszukujcej wartoci
42:
* waciwoci unauthenticatedIdentity. W pierwszej kolejnoci wywoywana
43:
* jest metoda klasy bazowej.
44:
*
45:
* @param options,
46:
* @option unauthenticatedIdentity: nazwa tosamoci, jak naley zastosowa
47:
* w przypadku podania pustej nazwy uytkownika oraz hasa.
48:
*/
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94: }
377
public void initialize(Subject subject,

CallbackHandler callbackHandler,
Map sharedState,
Map options)
{
super.initialize(subject, callbackHandler, sharedState,
options);
// Sprawdzenie opcji unauthenticatedIdentity.
Object option = options.get("unauthenticatedIdentity");
String name = (String) option;
if (name != null) {
unauthenticatedIdentity = new SimplePrincipal(name);
}
}
// ...
/**
* Metoda pozwalajca klasom pochodnym na zmian weryfikacji podanego
* hasa na podstawie hasa oczekiwanego. Ta wersja metody sprawdza,
* czy adne z przekazanych hase nie jest rwne null, a zwraca warto
* logiczn stanowic wynik porwnania obu przekazanych acuchw znakw.
*
* @return zwracana jest warto true, jeli haso inputPassword jest
* poprawne, w przeciwnym razie zwracana jest warto false.
*/
protected boolean validatePassword(String inputPassword,
String expectedPassword)
{
if (inputPassword == null || expectedPassword == null) {
return false;
}
return inputPassword.equals(expectedPassword);
}
/**
* Metoda pobiera oczekiwane haso dla biecej nazwy uytkownika,
* ktra jest okrelana przy uyciu metody getUsername(). Jest ona
* wywoywana przez metod login(), kiedy metoda CallbackHandler
* zwrci ju nazw uytkownika oraz podane przez niego haso.
*
* @return poprawne haso zwrcone jako String
*/
abstract protected String getUsersPassword()
throws LoginException;
Decyzja, ktr z klas bazowych AbstractServerLoginModule bd UsernamePasswordLoginModule naley zastosowa, sprowadza si do okrelenia, czy technologia uwierzytelniania, na potrzeby ktrej tworzony jest nowy modu logowania, zezwala na podawanie nazwy uytkownika oraz danych potwierdzajcych jego tosamo w formie
acuchw znakw. Jeli dane acuchowe mog by uywane, to naley tworzy modu
logowania w oparciu o klas UsernamePasswordLoginModule; w pozostaych sytuacjach
naley zastosowa klas AbstractServerLoginModule.
378
Czynnoci, jakie naley wykona podczas tworzenia niestandardowego moduu logowania, zale od zastosowanej abstrakcyjnej klas bazowej. Prac nad moduem logowania, ktry bdzie si integrowa z infrastruktur zabezpiecze, naley rozpocz od
stworzenia klasy dziedziczcej po AbstracServerLoginModule lub UsernamePasswordLoginModule; dziki temu mona mie pewno, e informacje o uwierzytelnionym
uytkowniku zwrcone w formie obiektu Principal bd mogy zosta wykorzystane
przez JBossSX.
W przypadku tworzenia moduu logowania dziedziczcego po AbstractServerLoginModule naley przesoni nastpujce metody:
void initialize(Subject,CallbackHandler,Map,Map) metoda ta jest
przesaniana, jeli trzeba przetwarza niestandardowe opcje.

boolean login() t metod przesania si w celu zaimplementowania
niestandardowego sposobu uwierzytelniania. Koniecznie naley pamita,

aby w przypadku pomylnego zakoczenia operacji logowania zmiennej
loginOk przypisa warto true, a w przeciwnym przypadku warto false.
Principal getIdentity() ta metoda jest przesaniana w celu zwrcenia
obiektu Principal reprezentujcego uwierzytelnionego uytkownika.
Group[] getRoleSets() metoda ta jest przesaniana, aby zwraca
przynajmniej jeden obiekt Gropu skojarzony z nazw Roles i zawierajcy role
przypisane uytkownikowi uwierzytelnionemu podczas wykonywania metody

login(). Drugim obiektem Group, ktry czsto jest zwracany przez t metod,
jest obiekt skojarzony z nazw CallerPrincipal; udostpnia on tosamo
uytkownika w aplikacji, a nie tosamo dziedziny zabezpiecze.

W przypadku tworzenia moduu logowania dziedziczcego po UsernamePasswordLoginModule przesaniane s nastpujce metody:
void initialize(Subject, CallbackHandler, Map, Map) metoda ta jest
przesaniana, jeli trzeba przetwarza niestandardowe opcje.

Group[] getRoleSets() metoda ta jest przesaniana, aby zwraca
przynajmniej jeden obiekt Group skojarzony z nazw Roles i zawierajcy role
przypisane uytkownikowi uwierzytelnionemu podczas wykonywania metody

login(). Drugim obiektem Group, ktry czsto jest zwracany przez t metod,
jest obiekt skojarzony z nazw CallerPrincipal; udostpnia on tosamo
uytkownika w aplikacji, a nie tosamo dziedziny zabezpiecze.

String getUserPassword() metoda ta jest przesaniana w celu zwrcenia
oczekiwanego hasa dla biecej nazwy uytkownika, ktr mona okreli przy
uyciu metody getUsername(). Metoda getUserPassword() jest wywoywana
wewntrz metody login() po tym, jak metoda zwrotna callbackhandler zwrci
nazw uytkownika oraz podane przez niego haso.
Przykad niestandardowego moduu logowania

W tej czci rozdziau zostanie stworzony przykadowy, niestandardowy modu logowania, ktry dziedziczy po klasie UsernamePasswordLoginModule i pobiera niezbdne
dane przy uyciu wyszukiwania JNDI. Modu ten zakada istnienie kontekstu JNDI,
379
ktrego przeszukanie zwraca haso uytkownika. Kontekst jest przeszukiwany przy

uyciu nazwy zapisanej w postaci password/<nazwaUytkownika>, gdzie <nazwaUytkownika> okrela aktualnie uwierzytelnianego uytkownika. Drugie przeszukanie, o postaci
roles/<nazwaUytkownika>, zwraca role podanego uytkownika.
Kod rdowy tego przykadu mona znale w materiaach doczonych do ksiki
w katalogu src/main/org/jboss/chap8/ex2. Kod rdowy moduu JndiUserAndPass zosta przedstawiony na listingu 8.11. Naley zwrci uwag, i klasa przedstawionego
moduu dziedziczy po UsernamePasswordLoginModule, dlatego te jedynymi operacjami,
jakie musi wykona, jest pobranie hasa uytkownika oraz jego rl przy uyciu JNDI.
Przedstawiony modu logowania nie zwraca uwagi na wszelkie operacje, jakie musz
wykonywa moduy LoginModule.
Listing 8.11. Niestandardowy modu logowania JndiUserAndPass
1: package org.jboss.chap8.ex2;
2:
3: import java.security.acl.Group;
4: import java.util.Map;
5: import javax.naming.InitialContext;
6: import javax.naming.NamingException;
7: import javax.security.auth.Subject;
8: import javax.security.auth.callback.CallbackHandler;
9: import javax.security.auth.login.LoginException;
10: import org.jboss.security.SimpleGroup;
11: import org.jboss.security.SimplePrincipal;
12: import org.jboss.security.auth.spi.UsernamePasswordLoginModule;
13:
14: /**
15: * Przykad niestandardowego moduu logowania, ktry pobiera
16: * haso oraz role uytkownika przy wykorzystaniu wyszukiwania JNDI.
17: *
18: * @author Scott.Stark@jboss.org
19: * @version $Revision: 1.5 $
20: */
21: public class JndiUserAndPass
22:
extends UsernamePasswordLoginModule
23: {
24:
/** Nazwa JNDI okrelajca kontekst obsugujcy wyszukiwanie password/username 25: */
26:
private String userPathPrefix;
27:
/** Nazwa JNDI okrelajca kontekst obsugujcy wyszukiwanie roles/username */
28:
private String rolesPathPrefix;
29:
30:
/**
31:
* T metod naley przesoni w celu pobrania wartoci opcji userPathPrefix
32:
* oraz rolesPathPrefix
33:
*/
34:
public void initialize(Subject subject, CallbackHandler callbackHandler,
35:
Map sharedState, Map options)
36:
{
37:
super.initialize(subject, callbackHandler, sharedState, options);
38:
userPathPrefix = (String) options.get("userPathPrefix");
39:
rolesPathPrefix = (String) options.get("rolesPathPrefix");
40:
}
41:
380

42:
/**
43:
* Metoda pobiera role, do jakich naley biecy uytkownik, poprzez
44:
* wyszukanie w kontekcie JNDI acucha
45:
* rolesPathPrefix + '/' + super.getUsername().
46:
*/
47:
protected Group[] getRoleSets() throws LoginException
48:
{
49:
try {
50:
InitialContext ctx = new InitialContext();
51:
String rolesPath = rolesPathPrefix + '/' + super.getUsername();
52:
String[] roles = (String[]) ctx.lookup(rolesPath);
53:
Group[] groups = {new SimpleGroup("Roles")};
54:
log.info("Pobieranie rl dla uytkownika="+super.getUsername());
55:
for(int r = 0; r < roles.length; r ++) {
56:
SimplePrincipal role = new SimplePrincipal(roles[r]);
57:
log.info("Odnaleziono rol="+roles[r]);
58:
groups[0].addMember(role);
59:
}
60:
return groups;
61:
} catch(NamingException e) {
62:
log.error("Nie udao si pobra grup dla uytkownika="+super.
getUsername(), e);
63:
throw new LoginException(e.toString(true));
64:
}
65:
}
66:
67:
/**
68:
* Metoda pobiera haso biecego uytkownika poprzez
69:
* wyszukanie w kontekcie JNDI acucha
70:
* userPathPrefix + '/' + super.getUsername().
71:
*/
72:
73:
protected String getUsersPassword()
74:
throws LoginException
75:
{
76:
try {
77:
InitialContext ctx = new InitialContext();
78:
String userPath = userPathPrefix + '/' + super.getUsername();
79:
log.info("Pobieranie hasa uytkownika="+super.getUsername());
80:
String passwd = (String) ctx.lookup(userPath);
81:
log.info("Odnaleziono haso="+passwd);
82:
return passwd;
83:
} catch(NamingException e) {
84:
log.error("Nie udao si odczyta hasa dla uytkownika="+super.
getUsername(), e);
85:
throw new LoginException(e.toString(true));
86:
}
87:
}
88: }
Szczegowe informacje na temat magazynu JNDI mona znale w komponencie

MBean org.jboss.chap8.ex2.service.JndiStore. Ta usuga wie obiekt ObjectFactory zwracajcy porednika javax.naming.Context z JNDI. Porednik ten obsuguje przeszukiwanie, dodajc do poszukiwanej nazwy uytkownika sowa password
lub roles. Jeli acuch uywany podczas przeszukiwania rozpoczyna si od sowa
381
password, to poszukiwane bdzie haso uytkownika; z kolei, jeli zaczyna si on od

sowa roles poszukiwane bd role, do jakich naley uytkownik. Przedstawiona
przykadowa implementacja moduu logowania zawsze, niezalenie od podanej nazwy
uytkownika, zwraca haso theduke oraz tablic nazw rl o postaci {"TheDuke", "Echo"}.
Oczywicie Czytelnik moe wyprbowa take inne implementacje moduu.
Kod przykadu zawiera take prosty komponent sesyjny sucy do testowania przedstawionego powyej moduu logowania. Aby przygotowa, wdroy i uruchomi ten
przykad, naley przej do katalogu zawierajcego materiay doczone do ksiki i wykona nastpujce polecenie:
C:\JBoss\przyklady>ant -Dchap=chap8 -Dex=2 run-example
...
run-example2:
[copy] Copying 1 file to /tmp/jboss-4.0.1/server/default/deploy
[java] [INFO,ExClient] Logowanie z uyciem danych: nazwa=jduke, haso=theduke
[java] [INFO,ExClient] Poszukiwanie EchoBean2
[java] [INFO,ExClient] Utworzono Echo
[java] [INFO,ExClient] Echo.echo('Witamy') = Witamy
19:06:13,266 INFO [EjbModule] Deploying EchoBean2
19:06:13,482 INFO [JndiStore] Start, bound security/store
19:06:13,486 INFO [SecurityConfig] Using JAAS AuthConfig:
jar:file:/private/tmp/jboss-4.0.1/
server/default/tmp/deploy/tmp23012chap8-ex2.jar-contents/chap8-ex2.sar!/META-INF/
login-config.xml
19:06:13,654 INFO [EJBDeployer] Deployed: file:/private/tmp/jboss-4.0.1/server/
default/deploy/chap8-ex2.jar
To, czy do uwierzytelniania uytkownikw po stronie serwera bdzie wykorzystywany niestandardowy modu logowania JndiUserAndPass, jest okrelane przez konfiguracj logowania przykadowej domeny bezpieczestwa. Domena bezpieczestwa jest
definiowana w pliku JAR META-INF/jboss.xml w nastpujcy sposb:
<jboss>
<security-domain>java:/jaas/chap8-ex2</security-domain>
</jboss>
Deskryptor pliku SER META-INF/login-config.xml definiuje konfiguracj moduu logowania w nastpujcy sposb:
<application-policy name = "chap8-ex2">
<authentication>
<login-module code="org.jboss.chap8.ex2.JndiUserAndPass"
flag="required">
<module-option name = "userPathPrefix">/security/store/password</
module-option>
<module-option name = "rolesPathPrefix">/security/store/roles</moduleoption>
</login-module>
</authentication>
382
Usuga DynamicLoginConfig
Domeny bezpieczestwa zdefiniowane w pliku login-config.xml s w zasadzie statyczne. Informacje o nich s odczytywane podczas uruchamiania serwera JBoss, jednak
nie ma adnej moliwoci pniejszego dodania nowej domeny bezpieczestwa lub
zmodyfikowania informacji o domenie ju zdefiniowanej. Na dynamiczne wdraanie
domen bezpieczestwa pozwala jednak usuga DynamicLoginConfig. Dziki temu moliwe jest okrelenie konfiguracji logowania JAAS jako jednego z elementw wdroenia (bd te jako niezalenej usugi) i nie trzeba ju rcznie wprowadza modyfikacji
w pliku login-config.xml.
Usuga DynamicLoginConfig udostpnia nastpujce atrybuty:
AuthConfig cieka okrelajca plik konfiguracyjny logowania, ktry ma
by uywany. Domylnie bdzie to plik login-config.xml.

LoginConfigService nazwa usugi XMLLoginConfig, ktrej naley uywa
do logowania. Usuga ta musi obsugiwa operacj String loadConfig(URL)
suc do wczytywania konfiguracji.

SecurityManagerService nazwa usugi SecurityMangerService uywanej
do usuwania zarejestrowanych domen bezpieczestwa. Usuga ta musi

udostpnia operacj flushAuthenticationCache(String) suc do usunicia
informacji o domenie bezpieczestwa o podanej nazwie. Wykonanie tej
operacji spowoduje, e po zatrzymaniu usugi pamici podrczne uywane
do uwierzytelniania zostan wyczyszczone.
Poniej przedstawiony zosta przykad definicji komponentu MBean korzystajcego
z usugi DynamicLoginConfig:
<server>
<mbean code="org.jboss.security.auth.login.DynamicLoginConfig" name="...">
<attribute name="AuthConfig">login-config.xml</attribute>

<depends optional-attribute-name="LoginConfigService">
jboss.security:service=XMLLoginConfig </depends>

<depends optional-attribute-name="SecurityManagerService">
jboss.security:service=JaasSecurityManager </depends>
</mbean>
</server>
383
Powysza definicja spowoduje wczytanie zasobu okrelonego w atrybucie AuthConfig

przy uyciu okrelonego komponentu MBean LoginConfigService, ktry wywoa metod loadConfig() i przekae do niej odpowiedni adres URL zasobu. Po zatrzymaniu
usugi, konfiguracja zostanie usunita. Zasb okrelany w atrybucie AuthConfig moe
by bd to plikiem XML, bd te konfiguracj logowania JAAS.
Protok
Secure Remote Password (SRP)
Protok SRP stanowi implementacj sposobu wymiany kluczy publicznych opisanego w pliku RFC 2945. Poniej przedstawiony zosta wycig z tego dokumentu:
Ten dokument opisuje mocny pod wzgldem kryptograficznym mechanizm
uwierzytelniania sieciowego nazywany protokoem Secure Remote Password
(SRP). Mechanizm ten nadaje si do negocjowania bezpiecznych pocze
sieciowych przy wykorzystaniu hasa podanego przez uytkownika,
a jednoczenie eliminuje tradycyjne problemy zwizane ze stosowaniem
hase uywanych wielokrotnie. Prezentowany system w ramach procesu
uwierzytelniania przeprowadza take bezpieczn wymian kluczy, dziki
czemu warstwy bezpieczestwa (zabezpieczenia prywatnoci oraz integralnoci)
mog by wczone w czasie trwania sesji. Korzystanie z prezentowanego
mechanizmu nie stwarza koniecznoci wykorzystywania zaufanych serwerw
kluczy ani infrastruktury zarzdzajcej certyfikatami, a klienty nie musz ani
przechowywa, ani zarzdza kluczami uywanymi przez duszy czas.
W porwnaniu z istniejcymi technikami typu wyzwanie-odpowied protok
SRP wykazuje wiele zalet, i to zarwno pod wzgldem bezpieczestwa,
jak i stosowania. Dziki temu doskonale si on nadaje do zastosowania
w rozwizaniach wymagajcych bezpiecznego uwierzytelniania przy
uyciu hasa.
Kompletn specyfikacj zawart w pliku RFC 2945 mona znale na witrynie
www.rfc-editor.org/rfc.html. Dodatkowe informacje dotyczce algorytmu SRP oraz jego historii s dostpne na witrynie http://srp.stanford.edu/.
Pod wzgldem oglnego rozwizania oraz zapewnianego bezpieczestwa protok SRP

przypomina inne algorytmy wymiany kluczy publicznych, takie jak algorytm Diffiego-Hellmana lub RSA. Protok SRP bazuje na prostych hasach tekstowych, jednak nie
stwarza koniecznoci przechowywania na serwerze hase zapisanych w niezaszyfrowanej postaci tekstowej. Pod tym wzgldem rni si on od innych algorytmw wymiany klucza publicznego, ktre wymagaj zastosowania certyfikatw klienta oraz niezbdnej infrastruktury zarzdzania tymi certyfikatami.
Algorytmy Diffiego-Hellmana lub RSA nazywane s algorytmami wymiany klucza
publicznego. Pomys dziaania takich algorytmw opiera si zaoeniu, e istniej dwa
klucze, z ktrych jeden jest publiczny i dostpny dla wszystkich, a drugi prywatny
384
i dostpny jedynie dla nas. Kiedy kto chce wysa do drugiej osoby zaszyfrowan informacj, szyfruje j przy uyciu klucza publicznego adresata. Tylko adresat bdzie
w stanie odszyfrowa t informacj, posugujc si swoim kluczem prywatnym. Rozwizanie to rni si od stosowanych wczeniej algorytmw szyfrowania wykorzystujcych klucz wsplny, ktre wymagay, by nadawca wiadomoci oraz jej odbiorca posugiwali si tym samym, wsplnym kluczem. Algorytmy klucza publicznego eliminuj
konieczno stosowania wsplnych hase.
Podsystem JBossSX zawiera implementacje protokou SRP skadajc si z nastpujcych elementw:
Implementacji protokou SRP z potwierdzeniem, ktra jest niezalena
od jakichkolwiek innych protokow klient-serwer.

Implementacji protokou z potwierdzeniem wykorzystujcej technologi RMI
i stanowicej domyln implementacj protokou SRM.

Moduu logowania JAAS LoginModule wykorzystujcego implementacj RMI
protokou i sucego do bezpiecznego uwierzytelniania klientw.

Komponentu JMX MBean sucego do zarzdzania implementacj serwera
RMI. Komponent ten pozwala, by obiekt stanowicy implementacj serwera

RMI zosta wczony do szkieletu JMX i umoliwia zewntrzn konfiguracj
magazynu informacji uywanych podczas weryfikacji. Dodatkowo komponent
ten tworzy pami podrczn przeznaczon na informacje uwierzytelniajce
powizan z przestrzeni nazw JNDI JBossa.
Dziaajcej po stronie serwera implementacji moduu logowania JAAS
LoginModule, ktra uywa pamici podrcznej z danymi uwierzytelniajcymi
zarzdzanymi przez komponent SRP JMX MBean.

Rysunek 8.14 przedstawia diagram kluczowych komponentw nalecych do implementacji protokou SRP w podsystemie JBossSX.
Po stronie klienta SRP jest widoczny jako implementacja niestandardowego moduu
logowania JAAS LoginModule, ktra komunikuje si z serwerem uwierzytelniajcym
przy uyciu porednika org.jboss.security.srp.SRPServerInterface. Klient uaktywnia uwierzytelnianie przy wykorzystaniu protokou SRP poprzez utworzenie w konfiguracji wpisu zawierajcego org.jboss.security.srp.jaas.SRPLoginModule. Modu ten
obsuguje nastpujce opcje konfiguracyjne:
principalClassName ta opcja nie jest ju obsugiwana. Obecnie zawsze jest
uywana klasa org.jboss.security.srp.jaas.SRPPrincipal.
srpServerJndiName ta opcja okrela nazw JNDI obiektu
SRPServerInterface, ktry ma by uywany do prowadzenia komunikacji
z serwerem uwierzytelniajcym SRP. Jeli podano zarwno opcj

srpServerJndiName, jak i opcj srpServerRmiUrl, to w pierwszej kolejnoci
zostanie wyprbowana pierwsza z nich.

srpServerRmiUrl ta opcja okrela adres URL protokou RMI okrelajcy
pooenie porednika SRPServerInterface, ktrego naley uywa podczas
prowadzenia komunikacji z serwerem uwierzytelniajcym SRP.
385
Rysunek 8.14. Komponenty implementacji protokou SRP stosowane po stronie klienta oraz serwera
externalRandomA ta opcja jest flag przyjmujc wartoci true lub false,
ktra okrela, czy metoda zwrotna klienta powinna zwraca losowo wybrany
fragment klucza publicznego A klienta. Metody tej mona uywa do podawania
mocnej pod wzgldem kryptograficznym liczby losowej odczytywanej,
na przykad, z jakiego urzdzenia.
hasAuxChallenge ta opcja jest flag przyjmujca wartoci true lub false,
ktra okrela, czy na serwer bdzie przesyane dodatkowe wyzwanie

zawierajce acuch znakw, ktre ten powinien zweryfikowa. Jeli sesja
klienta obsuguje szyfrowanie, to na podstawie prywatnego klucza sesji oraz
acucha przesanego jako obiekt javax.crypto.SealedObject zostanie
utworzony szyfr tymczasowy.
multipleSessions ta opcja jest flag przyjmujc wartoci true lub false,
ktra wskazuje, czy dany klient moe dysponowa kilkoma rwnoczenie

otwartymi sesjami logowani SRP.
Wszelkie dodatkowe przekazane opcje, ktre nie odpowiadaj powyszym, bd traktowane jako opcje JNDI uywane przez rodowisko przekazywane do konstruktora
klasy InitialContext. Moliwo ta jest przydatna w sytuacjach, gdy domylny obiekt
InitialContext nie jest w stanie zapewni dostpu do interfejsu serwera SRP.
386
Aby informacje uwierzytelniajce uywane przez protok SRP mogy by zastosowane w celu okrelenia moliwoci dostpu do komponentw J2EE zwizanych z systemem bezpieczestwa, modu SRPLoginModule musi by uywany razem ze standardowym moduem logowania ClientLoginModule. Poniej przedstawiony zosta fragment
wpisu konfigurujcego logowanie, ktry zapewnia wsplne wykorzystanie obu tych
moduw logowania:
srp {
org.jboss.security.srp.jaas.SRPLoginModule required
srpServerJndiName="SRPServerInterface"
;
org.jboss.security.ClientLoginModule required
password-stacking="useFirstPass"
;
};
Po stronie serwera JBoss istniej dwa komponenty MBean zarzdzajce obiektami,

ktre wsplnie stanowi serwer SRP. S to komponenty: org.jboss.security.srp.
SRPService oraz org.jboss.security.srp.SRPVerifierStoreService. Podstawow usug jest pierwszy z tych komponentw i to wanie on odpowiada za udostpnienie implementacji interfejsu SRPServerInterface, z ktrej mona korzysta za porednictwem
RMI, oraz za aktualizacj pamici podrcznej sesji uwierzytelniania SRP. Poniej przedstawione zostay atrybuty komponentu SRPService, ktrych wartoci mona okrela:
JndiName okrela nazw, pod ktr powinien by dostpny porednik
SRPServerInterface. To wanie w tym miejscu dynamiczny porednik jest
wizany z obiektem implementujcym interfejs SRPServerInterface. W razie
braku jawnego okrelenia wartoci tego atrybutu zostanie uyta warto

domylna srp/SRPServerVerifierSource.
VerifierSourceJndiName okrela nazw JNDI implementacji
SRPVerifierSource, ktra powinna by uywana przez obiekt SRPService.
Jeli nie zostanie jawnie podany, atrybut ten przyjmie warto

srp/DefaultVerifierSource.
AuthenticationCacheJndiName okrela nazw JNDI, pod jak zosta
powizany obiekt implementujcy interfejs org.jboss.util.CachePolicy,
ktry ma by uywanych do przechowywania informacji uwierzytelniajcych.

Pami podrczna sesji SRP bdzie dostpna przy uyciu wanie tej nazwy
JNDI. Jeli atrybut ten nie zosta podany jawnie, przyjmie on domyln warto
srp/AuthenticationCache.
ServerPort ten atrybut okrela numer portu, ktrego ma uywa obiekt
implementujcy interfejs SRPRemoteServerInterface. Jeli nie zosta on podany
jawnie, domylnie zostanie uyty port 10099.
ClientSocketFactory ten atrybut okrela nazw opcjonalnej, niestandardowej
klasy implementujcej interfejs java.rmi.server.RMIClientSocketFactory,
ktra ma by uywana podczas eksportowania obiektu typu SRPServerInterface.
Jeli atrybut ten nie zosta podany jawnie, przyjmie domyln warto
RMIClientSocketFactory.
387
ServerSocketFactory ten atrybut okrela nazw opcjonalnej, niestandardowej

klasy implementujcej interfejs java.rmi.server.RMIServerSocketFactory,
ktra ma by uywana podczas eksportowania obiektu typu SRPServerInterface.
Jeli atrybut ten nie zosta podany jawnie, przyjmie domyln warto
RMIServerSocketFactory.
AuthenticationCacheTimeout atrybut okrela wyraony w sekundach czas
przechowywania danych w buforze. Jego domyln wartoci jest 1800.
AuthenticationCacheResolution atrybut ten okrela, jak czsto naley
przeglda bufor w poszukiwaniu danych, ktrych okres skadowania ju

min. Czas tej jest okrelany w sekundach, a domylna warto atrybutu
wynosi 60.
RequireAuxChallenge jeli ten atrybut zostanie podany, to klient, w trakcie
fazy weryfikacji, bdzie przekazywa dodatkowe wyzwanie. Zapewnia

on kontrol nad tym, czy w konfiguracji moduu SRPLoginModule zostaa
uaktywniona opcja useAuxChallenge.
OverwriteSessions ten atrybut stanowi flag, ktra okrela, czy w przypadku
istniejcej sesji udane uwierzytelnienie uytkownika powinno spowodowa

nadpisanie biecej sesji. Atrybut ten kontroluje dziaanie pamici podrcznej
serwera SRP w przypadkach, gdy klient nie uaktywni obsugi wielu sesji.
Domylna warto tego atrybutu wynosi false, co oznacza, e kolejna prba
uwierzytelnienia uytkownika zakoczy si pomylnie, lecz nowa sesja SRP
nie nadpisze stanu poprzedniej sesji.
Jedynym ustawieniem wejciowym jest atrybut VerifierSourceJndiName. Okrela on
pooenie implementacji magazynu informacji o hasach SRP, ktra ma by udostpniona za porednictwem JNDI. Przykadem zastosowania implementacji interfejsu
SRPVerifierStore jest komponent MBean org.jboss.security.srp.SRPVerifierStoreService, w ktrej role trwaego magazynu peni plik obiektw serializowanych.
Cho zastosowanie tego komponentu w rodowisku produkcyjnym raczej nie jest prawdopodobne, to jednak pozwala on na testowanie protokou SRP, jak rwnie stanowi
przykad wymaga, jakie musi spenia usuga SRPVerifierStore. Poniej przedstawione zostay jego atrybuty:
JndiName nazwa JNDI, pod ktr jest dostpny obiekt implementujcy
interfejs SRPVerifierStore. Jeli nie zostanie okrelony, atrybut ten przyjmuje
warto domyln srp/DefaultVerifierSource.
StoreFile pooenie pliku obiektw serializowanych penicego rol
trwaego magazynu hase uywanych podczas weryfikacji. Moe to by

zarwno adres URL, jak i nazwa zasobu. Jeli nie zostanie podany, atrybut
ten przyjmuje domyln warto SRPVerifierStore.ser.
Komponent SRPVerfierStoreService obsuguje take operacje o nazwach addUser oraz
delUser suce odpowiednio do dodawania nowych uytkownikw oraz usuwania
uytkownikw ju zapisanych. Poniej przedstawione zostay sygnatury tych metod:
388

public void
throws
public void
throws
addUser(String nazwaUzytkownika, String haslo)

IOException;
delUser(String nazwaUzytkownika)
IOException;
Udostpnianie informacji o hasach

Najprawdopodobniej domylna implementacja interfejsu SRPVerfierStore nie bdzie
si nadawa do zastosowania w produkcyjnym rodowisku bezpieczestwa, gdy wymaga, by wszystkie informacje o hasach uytkownikw byy dostpne w postaci pliku serializowanych obiektw. A zatem konieczne bdzie stworzenie usugi MBean
udostpniajcej implementacj interfejsu SRPVerifierStore, ktra bdzie w stanie wsppracowa z istniejcymi magazynami informacji uywanych przez system bezpieczestwa. Kod rdowy interfejsu SRPVerifierStore zosta przedstawiony na listingu 8.12.
Listing 8.12. Interfejs SRPVerifierStore
1: package org.jboss.security.srp;
2:
3: import java.io.IOException;
4: import java.io.Serializable;
5: import java.security.KeyException;
6:
7: public interface SRPVerifierStore
8: {
9:
public static class VerifierInfo implements Serializable
10:
{
11:
/**
12:
* Nazwa uytkownika, ktrego dotycz informacje. Zapewne jest
13:
* to informacja nadmiarowa, jednak sprawia, e obiekt jest
14:
* spjn caoci niezalen od informacji zewntrznych.
15:
*/
16:
public String username;
17:
18:
/** Skrt wykorzystywany przez SRP do weryfikacji hasa */
19:
public byte[] verifier;
20:
/** Losowa dana inicjalizacyjna uyta pocztkowo do weryfikacji hasa */
21:
public byte[] salt;
22:
/** Tablica wartoci podstawowych algorytmu SRP */
23:
public byte[] g;
24:
/** Modu z bezpiecznej liczby pierwszej */
25:
public byte[] N;
26:
}
27:
28:
/**
29:
* Metoda zwraca informacje uywane do weryfikacji hasa
30:
* dla podanego uytkownika.
31:
*/
32:
public VerifierInfo getUserVerifier(String username)
33:
throws KeyException, IOException;
34:
/**
35:
* Metoda zapisuje informacje uywane podczas weryfikacji hasa
36:
* dla wskazanego uytkownika. Operacja ta odpowiada zmianie hasa
37:
* uytkownika i zazwyczaj powinna spowodowa uniewanienie
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56: }
389
* wszystkich istniejcych sesji SRP tego uytkownika oraz

* dotyczcych go informacji przechowywanych w pamici podrcznej.
*/
public void setUserVerifier(String username, VerifierInfo info)
throws IOException;
/**
* Metoda weryfikuje opcjonalne dodatkowe wyzwanie przesane przez
* klienta na serwer. Jeli obiekt auxCallenge zostanie przesany
* przez klienta w formie zaszyfrowanej, to po odebraniu go na
* serwerze zostanie on odszyfrowany. Przykadem takiego dodatkowego
* wyzwania byaby weryfikacja urzdzenia sprztowego (SafeWord, SecureID
* lub iButton), ktre serwer weryfikuje w celu jeszcze wikszego
* podniesienia bezpieczestwa wymiany kluczy realizowanej przez
* protok SRP.
*/
public void verifyUserChallenge(String username, Object auxChallenge)
throws SecurityException;
Podstawowym zadaniem klasy implementujcej interfejs SRPVerifierStore jest zapewnienie dostpu do obiektu SRPVerifierStore.VerifierInfo odpowiadajcego podanej nazwie uytkownika. Na pocztku sesji SRP obiekt SRPService wywouje metod
getUserVerifier(String) w celu pobrania parametrw niezbdnych do dziaania algorytmu wykorzystywanego przez protok SRP. Poniej opisane zostay elementy skadowe VerifierInfo:
username nazwa uytkownika lub identyfikator uywany podczas logowania.
verifier skrt (niemoliwy do odszyfrowania) hasa lub numeru
identyfikacyjnego, ktry uytkownik podaje w celu potwierdzenia swojej

tosamoci. Klasa org.jboss.security.Util dysponuje metod
calculateVerifier, ktra obsuguje wyznaczenie tego skrtu. Zwracane
haso jest wyznaczane zgodnie ze wzorem H(salt | H(username | ':' |
password)) opisanym w dokumencie RFC 2945. W tym przypadku H jest
funkcj wyznaczajc bezpieczny skrt SHA. Nazwa uytkownika jest
przeksztacana z acucha znakw na tablic bajtw przy wykorzystaniu
kodowania UTF-8.
salt liczba losowa suca do zwikszenia trudnoci przeprowadzenia
ataku sownikowego metod siy brutalnej. Atak taki mona przeprowadzi

w celu zamania bezpiecznych hase w przypadku udanego wamania do bazy
danych. Warto ta powinna by generowana w momencie wyznaczania skrtu
hasa podanego przez uytkownika przy uyciu algorytmu generujcego
liczby pseudolosowe w sposb mocny pod wzgldem kryptograficznym.
g algorytm SRP penicy rol generatora wartoci podstawowych. Oglnie
rzecz biorc, warto tej skadowej nie musi by okrelana niezalenie dla
kadego uytkownika, lecz by powszechnie znana. Klasa pomocnicza
org.jboss.security.srp.SRPConf posiada kilka ustawie tej skadowej,
w tym take dobr warto domyln, ktr mona pobra przy uyciu
metody SRPConf.getDefaultParams().g().
390

N modu bezpiecznej liczby pierwszej uywany przez algorytm SRP. Oglnie
rzecz biorc, warto tej skadowej nie musi by okrelana niezalenie

dla kadego uytkownika, lecz by powszechnie znana. Klasa pomocnicza
org.jboss.security.srp.SRPConf posiada kilka ustawie tej skadowej,
w tym take dobr warto domyln, ktr mona pobra przy uyciu
metody SRPConf.getDefaultParams().N().
Poniej przedstawione zostay czynnoci, jakie naley wykona w celu zintegrowania
protokou SRP z istniejcym magazynem hase:
1. Utworzy skrty hase. Jeli hasa ju s przechowywane w formie skrtw,
ktrych nie mona doprowadzi do postaci oryginalnej, to czynno t mona

wykona jedynie dla wybranych uytkownikw (na przykad jako etap procedury
aktualizacji danych). Naley zauway, e metoda setUserVerfier(String,
VerifierInfo) nie jest uywana przez aktualn wersj klasy SRPService
i moe by zaimplementowana jako metoda, ktra nie wykonuje adnych
operacji, a nawet moe zgasza wyjtek informujcy o tym, i magazyn hase
jest przeznaczony wycznie do odczytu.
2. Stworzy wasn implementacj interfejsu SRPVerifierStore, ktra bdzie
w stanie pobiera informacje z magazynu utworzonego w kroku 1. Metoda

verifyUserChallenge(String, Object) tego interfejsu jest wywoywana
wycznie w przypadku, gdy w konfiguracji moduu SRPLoginModule
dziaajcego po stronie klienta zosta podany atrybut hasAuxChallenge. Dziki
tej implementacji moliwe jest zintegrowanie z algorytmem SRP istniejcych
ju sposobw uwierzytelniania bazujcych na urzdzeniach sprztowych.
3. Stworzy komponent MBean, ktry zapewni, e zarwno obiekt klasy
napisanej w poprzednim kroku, jak i wszelkie konfigurowalne parametry bd

dostpne za porednictwem JNDI. Oprcz standardowego przykadu klasy
org.jboss.security.SRPVerifierStoreService przykad wykorzystania
protokou SRP przedstawiony w dalszej czci rozdziau pokazuje implementacj
klasy SRPVerifierStore korzystajcej z pliku waciwoci. Oba te przykady
powinny dostarczy Czytelnikowi dostatecznie duo informacji, aby by
w stanie zintegrowa protok SRP z istniejcym magazynem bezpieczestwa.
Szczegy dziaania algorytmu SRP

Atrakcyjno algorytmu SRP polega na tym, i pozwala on na wzajemne uwierzytelnienie klienta i serwera przy uyciu zwyczajnych hase tekstowych i to bez koniecznoci stosowania bezpiecznych kanaw komunikacyjnych. Mona si zastanawia, jak
to jest moliwe. Jeli Czytelnik jest zainteresowany szczegami dziaania oraz teori,
na jakiej bazuje ten algorytm, to wszelkie informacje na ten temat mona znale na
witrynie http://srp.stanford.edu. Uwierzytelnianie jest realizowane w szeciu krokach:
1. Dziaajcy po stronie klienta modu logowania SRPLoginModule pobiera,
przy uyciu usugi nazewniczej, instancj implementujc interfejs

SRPServerInterface i reprezentujc zdalny serwer obsugujcy
uwierzytelnianie.
391
2. Modu logowania dziaajcy po stronie klienta prosi o przekazanie parametrw
SRP skojarzonych z uytkownikiem, ktrego prbuje uwierzytelni.

Za pierwszym razem, gdy uytkownik poda haso, gdy jest ono przeksztacane
do sprawdzonej postaci uywanej przez algorytm SRP, konieczne jest podanie
kilku parametrw wykorzystywanych podczas jego dziaania. Parametrw
tych nie trzeba podawa na stae (co mona by zrobi, i to bez naraania si
na powane obnienie bezpieczestwa protokou) implementacja podsystemu
JBossSX pozwala na ich pobieranie w ramach protokou wymiany informacji;
suy do tego metoda getSRPParameters(nazwaUzytkownika).
3. Modu SRPLoginModule dziaajcy po stronie klienta rozpoczyna sesj SRP.
W tym celu tworzony jest obiekt SRPClientSession, przy czym podczas jego
tworzenia zostaje uyta nazwa uytkownika, jego haso oraz parametry SRP
pobrane w poprzednim kroku. Nastpnie klient tworzy losow liczb A,
ktra zostanie uyta do utworzenia klucza prywatnego sesji SRP. Kolejn
czynnoci, jak wykonuje klient, jest zainicjowanie operacji wykonywanych
po stronie serwera. W tym celu wywoywana jest metoda SRPServerInterface.
init, do ktrej zostaje przekazana nazwa uytkownika oraz wygenerowana
przez klienta losowa liczba A. Nastpnie serwer generuje swoj liczb losow
B i przekazuje j klientowi. Czynnoci te odpowiadaj wymianie kluczy
publicznych.
4. Modu logowania dziaajcy po stronie klienta pobiera prywatny klucz sesji SRP,
ktry zosta wygenerowany w wyniku wykonania czynnoci opisanych

w poprzednim kroku. Zostaje on zapisany w obiekcie Subject jako prywatne
informacje uwierzytelniajce. Odpowied M2 serwera wygenerowana w kroku
4. jest weryfikowana poprzez wywoanie metody SRPClientSession.verify.
Jeli jej wywoanie zakoczy si pomylnie, bdzie to oznacza, e wzajemne
uwierzytelnienie klienta przez serwer oraz serwera przez klienta zostao
zakoczone. Nastpnie modu SRPLoginModule dziaajcy po stronie serwera
tworzy wyzwanie M1, wywoujc w tym celu metod SRPClientSession.response
i przekazujc do niej losow liczb B (wygenerowan przez serwer). Wyzwanie
to jest przekazywane na serwer przy uyciu metody SRPServerInterface.verify,
a odpowied przesana z serwera jest zapisywana jako M2. Ten krok odpowiada
operacji przekazania wyzwa. W tym momencie serwer ma ju pewno,
e uytkownik jest tym, za kogo si podaje.
5. Modu logowania SRPLoginModule dziaajcy po stronie klienta zapisuje nazw
uytkownika oraz wyzwanie M1 w mapie sharedState (okrelanej w wywoaniu
metody LoginModule.initialize). Standardowa implementacja klasy
ClientLoginModule serwera JBoss uywa tej informacji jako nazwy tosamoci
oraz danych uwierzytelniajcych. Wyzwanie to jest uywane zamiast hasa

jako potwierdzenie tosamoci podczas wywoywania wszelkich metod
komponentw J2EE. M1 jest mocnym pod wzgldem kryptograficznym skrtem
skojarzonym z sesj SRP. Jego przechwycenie nie moe by wykorzystane
do odczytania hasa uytkownika.
6. Na samym kocu procesu uwierzytelniania obiekt SRPServerSession jest
umieszczany w pamici podrcznej obiektu SRPService w celu pniejszego
wykorzystania przez modu logowania SRPCacheLoginModule.
392
Cho protok SRP ma wiele bardzo interesujcych cech, niemniej jednak wci stanowi on rozwijajcy si element infrastruktury JBossSX i posiada kilka ogranicze,
o ktrych naley wiedzie. Oto one:
Ze wzgldu na sposb, w jaki JBoss odcza protok transportu metod
od kontenera komponentu, ktry dokonuje uwierzytelniania, nieuwierzytelniony

uytkownik moe przechwyci wyzwanie M1 i z powodzeniem zastosowa
je do przesyania da, podszywajc si pod uytkownika o podanej nazwie.
Problem ten mona rozwiza, tworzc niestandardowe obiekty przechwytujce,
ktre bd szyfrowa wyzwanie przy uyciu klucza sesji SRP.
Obiekt SRPService przechowuje informacje o sesjach SRP w pamici
podrcznej, ktrej wano wygasa po upyniciu okrelonego czasu. Kiedy

wano sesji upynie, kade zgoszone potem odwoanie do komponentu
J2EE zakoczy si niepowodzeniem, gdy obecnie nie ma jeszcze adnego,
niezauwaalnego dla uytkownika, sposobu ponownego negocjowania informacji
uwierzytelniajcych uywanych przez protok SRP. A zatem konieczne jest
ustawienie bardzo dugiego czasu wanoci pamici podrcznej (maksymalna
warto wynosi 2 147 483 647 sekund, czyli okoo 68 lat), bd to, w razie
niepowodzenia, obsugiwanie uwierzytelniania we wasnym kodzie.
Domylnie dla kadej nazwy uytkownika moe istnie tylko jedna sesja SRP.
Poniewa uzgodniona sesja SRP generuje klucz prywatny, ktry moe by

uywany do szyfrowania i deszyfrowania danych przekazywanych pomidzy
klientem a serwerem, zatem sesja w zasadzie zachowuje stan. JBoss obsuguje
wiele jednoczesnych sesji tego samego klienta z serwerem, jednak nie mona
szyfrowa danych przy uyciu klucza jednej sesji i deszyfrowa ich przy uyciu
klucza innej sesji.
Aby stosowa pene uwierzytelnianie wywoa komponentw J2EE, naley skonfigurowa domen bezpieczestwa odpowiadajc za ochron komponentw w taki sposb, by korzystaa z moduu logowania org.jboss.security.srp.jaas.SRPCacheLoginModule. Modu ten posiada tylko jedn opcj konfiguracyjn cacheJndiName
okrelajc nazw JNDI obiektu implementujcego interfejs CachePolicy. Nazwa ta
musi odpowiada wartoci atrybutu AuthenticationCacheJndiName komponentu MBean
SRPService. Modu SRPCacheLoginModule uwierzytelnia dane uytkownikw, pobierajc
z obiektu SRPServerSession (przechowywanego w pamici podrcznej) wyzwanie klienta
i porwnujc je z wyzwaniem przesanym jako element informacji uwierzytelniajcych uytkownika. Operacje wykonywane przez metod SRPCacheLoginModule.login
zostay przedstawione na rysunku 8.15.
Przykad SRP
W niniejszym rozdziale przedstawionych zostao stosunkowo duo informacji na temat
protokou SRP, nadszed wic czas, by przedstawi przykad demonstrujcy jego zastosowanie. Zamieszczony przykad prezentuje autoryzacj uytkownikw przeprowadzan
po stronie klienta przy wykorzystaniu SRP, jak rwnie pniejsze korzystanie z prostego komponentu EJB, podczas ktrego rol informacji uwierzytelniajcych uytkownika peni wyzwanie sesji SRP. Kod testowy realizuje wdroenie pliku JAR komponentu EJB zawierajcego archiwum SAR suce do skonfigurowania moduu
393
Rysunek 8.15.
Diagram sekwencji
ilustrujcy interakcj
pomidzy obiektem
SRPCacheLoginMod
ule oraz pamici
podrczn sesji SRP
logowania dziaajcego po stronie serwera oraz usug SRP. Podobnie jak w poprzednich przykadach take i w tym konfiguracja moduu logowania dziaajcego po
stronie serwera zostanie zainstalowana dynamicznie, przy uyciu komponentu MBean
SecurityConfig. Przedstawiony przykad wykorzystuje take niestandardow implementacj interfejsu SRPVerifierStore, ktra posuguje si magazynem przechowywanym
w pamici i inicjowanym przez dane zapisane w pliku waciwoci, a nie w magazynie obiektw serializowanych (jakiego uywa klasa SRPVerifierStoreService). Ta niestandardowa klasa nosi nazw org.jboss.chap8.ex3.service.PropertiesVerifierStore. Ponisza lista przedstawia zawarto pliku JAR, w ktrym zosta umieszczony
przykadowy komponent EJB oraz usugi SRP:
C:\JBoss\przyklady>java -cp output/classes ListJar output/chap8/chap8-ex3.jar
output/chap8/chap8-ex3.jar
+- META-INF/MANIFEST.MF
+- META-INF/ejb-jar.xml
+- META-INF/jboss.xml
+- org/jboss/chap8/ex3/Echo.class
+- org/jboss/chap8/ex3/EchoBean.class
+- org/jboss/chap8/ex3/EchoHome.class
+- roles.properties
+- users.properties
+- chap8-ex3.sar (archive)
| +- META-INF/MANIFEST.MF
| +- META-INF/jboss-service.xml
| +- META-INF/login-config.xml
| +- org/jboss/chap8/ex3/service/PropertiesVerifierStore$1.class
| +- org/jboss/chap8/ex3/service/PropertiesVerifierStore.class
| +- org/jboss/chap8/ex3/service/PropertiesVerifierStoreMBean.class
| +- org/jboss/chap8/service/SecurityConfig.class
| +- org/jboss/chap8/service/SecurityConfigMBean.class
394
Kluczowymi elementami tego przykadu, zwizanymi z zastosowaniem protokou SRP,

s konfiguracja komponentu MBean usugi SRP oraz konfiguracja moduu logowania SRP. Listing 8.13 przedstawia plik jboss-service.xml zawierajcy deskryptor
chap8-ex3.sar, natomiast listingi 8.14 oraz 18.15 prezentuj odpowiednio konfiguracje moduw logowania dziaajcych po stronie klienta oraz po stronie serwera.
Listing 8.13. Deskryptor usug SRP umieszczony w pliku jboss-service.xml
<?xml version="1.0" encoding="UTF-8"?>
<server>
<!-Konfiguracja niestandardowego logowania instalujca
obiekt Configuration pozwalajcy na dynamiczn aktualizacj
ustawie konfiguracyjnych.
-->
<mbean code="org.jboss.chap8.service.SecurityConfig"
name="jboss.docs.chap8:service=LoginConfig-EX3">
<attribute name="AuthConfig">META-INF/login-config.xml</attribute>
<attribute name="SecurityConfigName">jboss.security:service=
XMLLoginConfig</attribute>
</mbean>

<mbean code="org.jboss.security.srp.SRPService"
name="jboss.docs.chap8:service=SRPService">
<attribute name="VerifierSourceJndiName">srp-test/chap8-ex3</attribute>
<attribute name="JndiName">srp-test/SRPServerInterface</attribute>
<attribute name="AuthenticationCacheJndiName">srptest/AuthenticationCache</attribute>
<attribute name="AuthenticationCacheTimeout">10</attribute>
<attribute name="AuthenticationCacheResolution">5</attribute>
<attribute name="ServerPort">0</attribute>
<depends>jboss.docs.chap8:service=PropertiesVerifierStore</depends>
</mbean>

<mbean code="org.jboss.chap8.ex3.service.PropertiesVerifierStore"
name="jboss.docs.chap8:service=PropertiesVerifierStore">
<attribute name="JndiName">srp-test/chap8-ex3</attribute>
</mbean>
</server>
Listing 8.14. Standardowa konfiguracja moduu logowania dziaajcego po stronie klienta

srp {
org.jboss.security.srp.jaas.SRPLoginModule required
srpServerJndiName="srp-test/SRPServerInterface"
;
};
org.jboss.security.ClientLoginModule required
password-stacking="useFirstPass"
;
395
Listing 8.15. Konfiguracja moduu logowania XMLLoginConfig dziaajcego po stronie serwera

<application-policy name="chap8-ex3">
<authentication>
<login-module code="org.jboss.security.srp.jaas.SRPCacheLoginModule"
flag = "required">
<module-option name="cacheJndiName">srp-test/AuthenticationCache</
module-option>
</login-module>
flag = "required">
</login-module>
</authentication>
Przykadowymi usugami uywanymi w tym przykadzie s komponenty MBean:

ServiceConfig, PropertiesVerifierStore oraz SRPService. Warto zwrci uwag, i
atrybut JndiName komponentu PropertiesVerifierStore ma tak sam warto jak ten
sam atrybut komponentu VerifierSourceJndiName oraz e komponent SRPService jest
zaleny od komponentu PropertiesVerifierStore. Zaleno tak jest niezbdna, gdy
komponent SRPService potrzebuje implementacji interfejsu SRPVerifierStore w celu
uzyskania dostpu do informacji uywanych podczas weryfikacji hase uytkownikw.
Konfiguracja moduu logowania dziaajcego po stronie klienta uywa moduu SRPLoginModule oraz wartoci opcji srpServerJndiName, ktra odpowiada wartoci atrybutu
SRPServiceJndiName (srptest/SRPServerInterface) komponentu serwera. Niezbdny
jest take modu ClientLoginModule, w ktrego konfiguracji zosta umieszczony atrybut password-stacking="useFirstPass", dziki czemu informacje uwierzytelniajce uytkownikw generowane przez modu SRPLoginModule bd przekazywane do warstwy
wywoujcej EJB.
Jeli chodzi o konfiguracj moduu logowania dziaajcego po stronie serwera, to naley
w niej zwrci uwag na dwa zagadnienia. Przede wszystkim opcja konfiguracyjna
cacheJndiName=srp-test/AuthenticationCache przekazuje moduowi SRPCacheLoginModule informacj o lokalizacji obiektu CachePolicy zawierajcego obiekty SRPServerSession reprezentujce uytkownikw, ktrzy zostali ju uwierzytelnieni przez SRPService. Warto ta odpowiada wartoci atrybutu AuthenticationCacheJndiName
usugi SRPService. Poza tym konfiguracja zawiera dane moduu UserRolesLoginModule,
wrd ktrych zostaa umieszczona opcja password-stacking=useFirstPass. Zastosowanie drugiego moduu logowania wraz z moduem SRPCacheLoginModule jest konieczne, gdy protok SRP suy jedynie do uwierzytelniania. Drugi modu logowania
musi by skonfigurowany tak, by akceptowa informacje uwierzytelniajce zweryfikowane przez modu SRPCacheLoginModule oraz by okrela role przypisane danej tosamoci w celu okrelenia jej uprawnie. Modu logowania UserRolesLoginModule
uzupenia zatem proces uwierzytelniania realizowany przez protok SRP o moliwoci
autoryzacji wykorzystujcej informacje zapisane w pliku waciwoci. Role uytkownikw s odczytywane z pliku roles.properties doczonego do archiwuj JAR zawierajcego komponent EJB.
396
Teraz mona ju uruchomi klienta, przechodzc do katalogu zawierajcego przykad

i wykonujc nastpujce polecenie:
...
run-example3:
[java] Rejestracja przy uyciu konfiguracji 'srp'
[java] Utworzono Echo
[java] Echo.echo()#1 = To jest wywoanie nr. 1
W katalogu przyklady/logs mona znale plik o nazwie ex3-trace.log. Zawiera on

szczegowy dziennik operacji wykonywanych przez cz algorytmu SRP dziaajc
po stronie klienta. Dzienniki tego typu dokumentuj krok po kroku proces tworzenia
kluczy publicznych, wyzwa, klucza sesji oraz weryfikacji.
Czytelnik na pewno zwrci uwag, i w porwnaniu z innymi prostymi przykadami
wykonanie tego klienta zabiera stosunkowo duo czasu. Wynika to z faktu, i klient
musi wygenerowa swj klucz prywatny, a to z kolei wymaga wygenerowania mocnej pod wzgldem kryptologicznym liczby losowej. To wanie wykonanie tego procesu zabiera tak wiele czasu. Na szczcie generacja klucza jest wykonywana tylko za
pierwszym razem gdyby pojawia si konieczno ponownego zalogowania klienta
na tej samej wirtualnej maszynie Javy, cay proces zabraby znacznie mniej czasu. Naley take zwrci uwag, i drugie wywoanie metody Echo.echo() (Echo.echo()#2)
zgasza wyjtek informujcy o niepowodzeniu uwierzytelniania. Po wykonaniu pierwszego wywoania metody echo() klient czeka 15 sekund i prbuje ponownie wykona
t metod; w ten sposb przykad demonstruje skutki dziaania czasu wanoci informacji przechowywanych w pamici podrcznej usugi SRPService. Aby umoliwi takie
dziaanie przykadu, czas wanoci pamici podrcznej usugi SRPService zosta ustawiony na 10 sekund. Zgodnie z informacjami podanymi we wczeniejszej czci rozdziau zazwyczaj czas wanoci pamici podrcznej powinien by bardzo dugi, bd te
naley obsugiwa ponowne uwierzytelnianie.
Uruchamianie serwera JBoss z uyciem

menedera bezpieczestwa Java 2
Domylnie serwer JBoss nie uywa menedera bezpieczestwa udostpnianego przez
platform Java 2. Jeli chcemy, by przywileje kodu byy okrelane na podstawie informacji o uprawnieniach, jakimi dysponuje platforma Java 2, to konieczne bdzie
skonfigurowanie serwera JBoss w taki sposb, by uywa menedera bezpieczestwa
Java 2. W tym celu naley odpowiednio skonfigurowa opcje wirtualnej maszyny Javy
podane w plikach run.bat lub run.sh umieszczonych w podkatalogu bin katalogu instalacyjnego JBossa. Chodzi konkretnie o dwie opisane poniej opcje:
397
java.security.manager jeli warto tej opcji nie zostanie jawnie okrelona,
bdzie to oznacza, e naley uy domylnego menedera bezpieczestwa.

Stosowanie menedera domylnego jest rozwizaniem preferowanym.
Jednak mona take okreli warto tej opcji, aby zastosowa niestandardow
implementacj menedera bezpieczestwa. Warto ta musi zawiera pen
nazw klasy dziedziczcej po klasie java.lang.SecurityManager. Bdzie
to oznacza, e plik regu bezpieczestwa powinien rozszerza domylne
zasady zabezpiecze skonfigurowane w instalacji wirtualnej maszyny Javy.
java.security.policy ta opcja pozwala na okrelenie pliku regu
bezpieczestwa, ktry bdzie rozszerza domylne informacje dotyczce regu

bezpieczestwa wirtualnej maszyny Javy. Warto tej opcji mona podawa
w dwch postaciach: java.security.policy=URL_pliku_regu bd
java.security.policy==URL_pliku_regu. Uycie pierwszego sposobu zapisu
oznacza, e wskazany plik regu powinien zmodyfikowa i rozszerzy domylny
zestaw regu bezpieczestwa okrelony podczas instalacji wirtualnej maszyny
Javy. Z kolei drugi zapis mwi, e naley zastosowa zasady bezpieczestwa
okrelone wycznie we wskazanym pliku. Warto opcji URL_pliku_regu
moe zawiera dowolny adres URL dla ktrego zdefiniowano metod obsugi
protokou; ewentualnie moe te okrela ciek dostpu do pliku.
Oba skrypty suce do uruchamiania serwera JBoss, zarwno run.bat, jak i run.sh,
odwouj si do zmiennej rodowiskowej JAVA_OPTS, ktr mona wykorzysta do okrelenia waciwoci menedera bezpieczestwa.
Uaktywnienie menedera bezpieczestwa Java 2 jest prost czci caego zagadnienia. Znacznie trudniejszym zadaniem jest okrelenie przydzielonych uprawnie. Jeli
zajrzymy do pliku server.policy umieszczonego w domylnym zbiorze plikw konfiguracyjnych, to okae si, e zawiera on nastpujcy wpis:
grant {
3
// Allow everything for now
permission java.security.AllPermission;
};
Powyszy wpis w praktyce oznacza wyczenie sprawdzania wszystkich uprawnie niezalenie od wykonywanego kodu; innymi sowy, powyszy zapis stwierdza, i dowolny
kod moe wykona dowoln operacj, co oczywicie nie jest zbyt rozsdne. Okrelenie sensownego zbioru uprawnie pozostaje w gestii autorw aplikacji.
Tabela 8.1 przedstawia zbir aktualnie dostpnych uprawnie java.lang.RuntimPermissions (odnoszcych si do serwera JBoss), ktrych okrelenie jest wymagane.
W ramach zakoczenia tej dyskusji poniej podana zostaa stosunkowo mao znana informacja dotyczca ustawie regu bezpieczestwa zwizanych z testowaniem. Ot istnieje moliwo stosowania flag okrelajcych, w jaki sposb meneder bdzie uywa
pliku regu bezpieczestwa oraz jaki plik zawiera informacje dotyczce uprawnie.
Przedstawione poniej wywoanie programu java wywietla wszystkie moliwe wartoci flagi testujcej:
3
Zezwalamy na wszystko
398
Tabela 8.1. Wymagane uprawnienia java.lang.RuntimePermissions odnoszce si do JBossa

Nazwa
Na co zezwala to uprawnienie
Zagroenia
org.jboss.security.
SecurityAssociation.
getPrincipalInfo
Dostp do metod org.jboss.

security.SecurityAssociation.
getPrincipal() oraz
getPrincipals().
Moliwo zdobycia informacji

o obiekcie, ktry spowodowa
uruchomienie biecego wtku, oraz
jego informacji uwierzytelniajcych.
org.jboss.security.
setPrincipalInfo

setPrincipal() oraz
setPrincipals().
Moliwo okrelenia obiektu, ktry

spowodowa uruchomienie biecego
wtku, oraz jego informacji
uwierzytelniajcych.
org.jboss.security.
setServer
Dostp do metody org.jboss.

setServer().
Moliwo uaktywnienia
lub dezaktywacji wielowtkowego
przechowywania tosamoci oraz
danych uwierzytelniajcych obiektu,
ktry spowodowa uruchomienie
biecego wtku.
org.jboss.security.
setRunAsRole

pushRunAsRole() oraz popRunAsRole.
Moliwo zmiany tosamoci roli,

jakiej uywa biecy wtek.
C:\JBoss\przyklady>java -Djava.security.debug=help
all
access
combiner
jar
logincontext
policy
provider
scl
turn on all debugging

print all checkPermission results
SubjectDomainCombiner debugging
jar verification
login context results
loading and granting
security provider debugging
permissions SecureClassLoader assigns
The following can be used with access:

stack
domain
failure
include stack trace

dumps all domains in context
before throwing exception, dump stack
and domain that didn't have permission
Note: Separate multiple options with a comma
Zastosowanie opcji -Djava.security.debug=all powoduje wygenerowanie najwikszej

iloci informacji i rzeczywicie jest ich bardzo duo. By moe to wanie od tej opcji
naley zacz, jeli w ogle nie rozumiemy powodw, z jakich meneder bezpieczestwa nie pozwala na wykonanie zamierzonych operacji. Kolejnymi opcjami przydatnymi podczas okrelania przyczyn problemw zwizanych z uprawnieniami, ktre
jednak generuj nieco mniej informacji, s: -Djava.security.debug=access,failure.
Take w tym przypadku informacje s obszerne, jednak sytuacja nie jest a tak za jak
w przypadku zastosowania opcji all, gdy informacje zwizane z domen bezpieczestwa s wywietlane wycznie w przypadku niepowodze.
399
Zastosowanie protokou SSL

przy uyciu JSSE
Do obsugi protokou SSL JBoss wykorzystuje rozszerzenie JSSE (ang. Java Secure
Socket Extension). Stanowi ono jeden z elementw platformy JDK 1.4. Aby mc rozpocz korzystanie z niego, naley uzyska par kluczy prywatny i publiczny zapisanych w postaci certyfikatu X509. Klucze te bd wykorzystywane przez gniazda
SSL serwera. Na potrzeby przykadw zamieszczonych w niniejszej ksice wygenerowano certyfikat przy uyciu programu keytool (wchodzcego w skad JDK), a wynikowy plik umieszczono w katalogu chap8 pod nazw chap8.keystore. Plik ten zosta
wygenerowany przy uyciu nastpujcego polecenia:
keytool -genkey -keystore chap8.keystore -storepass rmi+ssl -keypass rmi+ssl
-keyalg RSA -alias chapter8 -validity 3650 -dname "cn=chapter8 example,ou=admin
book,dc=jboss,dc=org"
Wykonanie powyszego polecenia powoduje utworzenie pliku magazynu kluczy (ang.

keystore) o nazwie chap8.keystore (magazyn kluczy to baza danych zawierajca klucze
uywane przez systemy bezpieczestwa). W magazynie kluczy umieszczane s dwa
rodzaje wpisw:
Klucze kady wpis tego typu zawiera bardzo wraliwe, poufne informacje
dotyczce kluczy kryptograficznych, ktre, w celu uniemoliwienia dostpu

osb nieupowanionych, s przechowywane w zabezpieczonym formacie.
Zazwyczaj kluczem przechowywanym we wpisach tego typu jest klucz tajny
lub klucz prywatny wraz z doczonym do niego acuchem certyfikatw
odpowiedniego klucza publicznego. Programy keytool oraz jarsigner s
w stanie obsugiwa jedynie wpisy tego drugiego rodzaju, czyli te, w ktrych
s umieszczane klucze prywatne wraz z acuchem certyfikatw.
Zaufane certyfikaty kady wpis tego typu zawiera jeden certyfikat klucza
publicznego nalecego do kogo innego. Nosi on nazw zaufanego certyfikatu,

gdy waciciel magazynu kluczy ufa, i klucz publiczny zapisany w certyfikacie
faktycznie naley do osoby bdcej podmiotem (wacicielem) certyfikatu.
Wystawca certyfikatu, podpisujc go, rczy, e tosamo jego waciciela
jest poprawna.
Poniej przedstawione zostay wyniki wywietlenie zawartoci pliku src/main/org/
jboss/chap8/chap8.keystore przy uyciu programu keytool:
C:\JBoss\przyklady>keytool -list -v -keystore src/main/org/jboss/chap8/chap8.keystore
Enter keystore password: rmi+ssl
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: chapter8
Creation date: 2004-12-17
Entry type: keyEntry
400

Certificate chain length: 1
Certificate[1]:
Owner: CN=chapter8 example, OU=admin book, DC=jboss, DC=org
Issuer: CN=chapter8 example, OU=admin book, DC=jboss, DC=org
Serial number: 41c23d6c
Valid from: Thu Dec 16 19:59:08 CST 2004 until: Sun Dec 14 19:59:08 CST 2014
Certificate fingerprints:
MD5: 36:29:FD:1C:78:44:14:5E:5A:C7:EB:E5:E8:ED:06:86
SHA1: 37:FE:BB:8A:A5:CF:D9:3D:B9:61:8C:53:CE:19:1E:4D:BC:C9:18:F2
*******************************************
*******************************************
Kiedy rozszerzenie JSSE bdzie poprawnie dziaa, a magazyn kluczy zawierajcy

niezbdny certyfikat zosta ju wygenerowany, mona przystpi do konfiguracji serwera JBoss tak, by dostp do komponentw EJB odbywa si przy uyciu protokou SSL.
W tym celu naley odpowiednio skonfigurowa fabryki gniazd RMI obiektu wywoujcego EJB. Podsystem JBossSX zawiera implementacje interfejsw java.rmi.server.
RMIServerSocketFactory oraz java.rmi.server.RMIClientSocketFactory, ktre pozwalaj na stosowanie RMI wraz z gniazdami obsugujcymi komunikacje szyfrowan
przy uyciu protokou SSL. Interfejsy te s odpowiednio implementowane przez klasy: org.jboss.security.ssl.RMISSLServerSocketFactory oraz org.jboss.security.ssl.
RMISSLClientSocketFactory. Rozpoczcie wykorzystania protokou SSL w celu odwoywania si do komponentw EJB wymaga wykonania dwch operacji. Pierwsz z nich
jest wczenie wykorzystania magazynu kluczy jako bazy danych zawierajcej certyfikaty SSL serwera. Operacja ta wymaga odpowiedniego skonfigurowania komponentu MBean org.jboss.security.plugins.JaasSecurityDomain. Stosowny deskryptor umieszczony w pliku jboss-service.xml w katalogu chap8/ex4 zosta przedstawiony
na listingu 8.16.
Listing 8.16. Przykadowa konfiguracja JaasSecurityDomain w przypadku zastosowania RMI i SSL

<mbean code="org.jboss.security.plugins.JaasSecurityDomain"
name="jboss.security:service=JaasSecurityDomain,domain=RMI+SSL">
<constructor>
<arg type="java.lang.String" value="RMI+SSL"/>
</constructor>
<attribute name="KeyStoreURL">chap8.keystore</attribute>
<attribute name="KeyStorePass">rmi+ssl</attribute>
</mbean>
Klasa JaasSecurityDomain dziedziczy po standardowej klasie JaasSecurityManager

i dodaje do niej obsug magazynw kluczy oraz moliwoci dostpu do obiektw typu KeyManagerFactory oraz TrustManagerFactory. Rozbudowuje ona moliwoci standardowego menadera bezpieczestwa o obsug protokou SSL oraz innych operacji
kryptograficznych wymagajcych uycia kluczy. Przedstawiona powyej konfiguracja powoduje po prostu wczytanie magazynu kluczy chap8.keystore (z pliku SAR tworzonego w przykadzie 4.) przy wykorzystaniu wskazanego hasa.
401
Drugim krokiem jest zdefiniowanie konfiguracji obiektu wywoujcego EJB, ktry

bdzie korzysta z obiektw fabrykujcych gniazda RMI obsugujce protok SSL.
W tym celu naley zdefiniowa wasn konfiguracje obiektu JRMPInvoker zgodnie z informacjami zamieszczonymi w rozdziale 5., Komponenty EJB w JBossie, jak rwnie przygotowa konfiguracje komponentu EJB, ktry bdzie uywa tego obiektu
wywoujcego. Poniszy fragment pliku jboss-service.xml przedstawia deskryptor definiujcy niestandardowy obiekt JRMPInvoker:
<mbean code="org.jboss.invocation.jrmp.server.JRMPInvoker"
name="jboss:service=invoker,type=jrmp,socketType=SSL">
<attribute name="RMIObjectPort">14445</attribute>
<attribute name="RMIClientSocketFactory">
org.jboss.security.ssl.RMISSLClientSocketFactory
</attribute>
<attribute name="RMIServerSocketFactory">
org.jboss.security.ssl.RMISSLServerSocketFactory
</attribute>
<attribute name="SecurityDomain">java:/jaas/RMI+SSL</attribute>
<depends>jboss.security:service=JaasSecurityDomain,domain=RMI+SSL</depends>
</mbean>
W celu skonfigurowania obiektu wywoujcego uywajcego protokou SSL naley

stworzy powizanie o nazwie stateless-ssl-invoker uywajce niestandardowego
obiektu JRMPInvoker. Poniszy plik jboss.xml pokazuje, w jaki sposb mona utworzy
takie powizanie i poczy je z komponentem EchoBean4:
<jboss>
<enterprise-beans>
<session>
<ejb-name>EchoBean4</ejb-name>
<configuration-name>Standardowy bezstanowy komponent sesyjny</
configuration-name>
<invoker-bindings>
<invoker>
<invoker-proxy-binding-name>
stateless-ssl-invoker
</invoker-proxy-binding-name>
</invoker>
</invoker-bindings>
</session>
</enterprise-beans>
<invoker-proxy-bindings>
<invoker-proxy-binding>
<name>stateless-ssl-invoker</name>
<invoker-mbean>jboss:service=invoker,type=jrmp,socketType=SSL</invokermbean>
<proxy-factory>org.jboss.proxy.ejb.ProxyFactory</proxy-factory>
<proxy-factory-config>
<client-interceptors>
<home>
<interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor>
<interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
<interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
402

</home>
<bean>
<interceptor>org.jboss.proxy.ejb.StatelessSessionInterceptor
</interceptor>
<interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
<interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
<interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
</bean>
</client-interceptors>
</proxy-factory-config>
</invoker-proxy-binding>
</invoker-proxy-bindings>
</jboss>
Kod przykadu 4. umieszczony jest w przykadach doczonych do niniejszej ksiki

w katalogu src/main/org/jboss/chap8/ex4. Przykad ten zawiera kolejny prosty bezstanowy komponent sesyjny udostpniajcy metod echo, ktra zwraca przekazany argument. Jeli nie pojawi si adne problemy z wykorzystaniem protokou SSL, to bardzo trudno jest okreli, kiedy jest on stosowany; dlatego te, aby si upewni, e
podczas odwoywania si do komponentu EJB faktycznie jest wykorzystywany protok SSL, przedstawiony przykad mona uruchamia na dwa rne sposoby. Najpierw
naley uruchomi serwer JBoss, uywajc przy tym standardowej konfiguracji, a nastpnie wykona przykad 4b w sposb nastpujcy:
C:\JBoss\przyklady>ant -Dchap=chap8 -Dex=4b run-example
...
run-example4b:
...
[java] Exception in thread "main" java.rmi.ConnectIOException: error during JRMP
connection establishment; nested exception is:
[java]
javax.net.ssl.SSLHandshakeException: sun.security.validator.
ValidatorException: No trusted certificate found
...
Pojawienie si wyjtku, jaki zostanie w tym przypadku zgoszony, jest cakowicie zgodne z oczekiwaniami; taki by cel przygotowania tego przykadu. Warto zwrci uwag, i zamieszczone powyej informacje o zgoszonych wyjtkach zostay rcznie sformatowane w celu poprawienia ich przejrzystoci w tekcie ksiki; z tego wzgldu wyniki
uzyskane przez Czytelnika podczas uruchamiania tego przykadu mog mie nieco
inn posta. Kluczowym aspektem tego przykadu jest fakt, e zgoszony wyjtek jasno pokazuje, i do komunikacji z kontenerem EJB serwera JBoss uywane s klasy
JSSE firmy Sun. Wyjtek ten informuje, i weryfikacja certyfikatu, ktry jest uywany w przykadzie jako certyfikat serwera JBoss, wykazaa, e jest zosta on podpisany
przez adn z domylnych instytucji certyfikujcych. Takiego wyniku mona si byo
spodziewa, gdy domylny magazyn kluczy instytucji certyfikujcych dostarczany
wraz z pakietem JSSE zawiera jedynie powszechnie znane instytucje, takie jak VeriSign,
Thawte oraz RSA Data Security. Aby klient EJB uzna, i samodzielnie podpisany certyfikat jest wany, naley poinstruowa klasy JSSE, by korzystay z zaufanego magazynu (ang. truststore) chap8.keystore (magazyn zaufany to magazyn kluczy zawierajcy certyfikaty klucza publicznego uytego do podpisywania innych certyfikatw).
403
W tym celu naley uruchomi przykad 4., uywajc przy tym opcji -Dex=4, a nie opcji
-Dex=4b, aby przekaza pooenie odpowiedniego zaufanego magazynu przy uyciu
waciwoci systemowej javax.net.ssl.trustStore:
...
run-example4:
...
[java] Created Echo
Tym razem jedyn informacj o tym, i wykorzystywane s gniazda SSL, jest komunikat SSL handshakeCompleted. Jest to komunikat poziomu testowania rejestrowany
w dzienniku, a generuje go klasa RMISSLClientSocketFactory. Jeli jednak klient nie
zosta skonfigurowany w taki sposb, by komunikaty poziomu testowania generowane przez bibliotek log4j byy wywietlane, to nie pojawi si adna informacja o wykorzystaniu protokou SSL. Powan rnic zauwaymy jednak, jeli przyjrzymy si
czasom dziaania oraz obcieniu procesora. Protok SSL, podobnie jak SRP, wymaga
zastosowania liczb losowych mocnych pod wzgldem kryptograficznym, ktrych
zainicjowanie podczas pierwszego uycia zabiera wiele czasu. To wanie generacja
liczb losowych jest tak wyranie widoczna w uyciu procesora i czasie uruchamiania
programu.
W konsekwencji, jeli Czytelnik bdzie uruchamia opisywane przykady, choby przykad 4b, na komputerze wolniejszym od tego, na jakim byy one tworzone, to moe
wystpi wyjtek podobny do poniszego:
javax.naming.NameNotFoundException: EchoBean4 not bound
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer
...
Powyszy problem wynika z faktu, i serwer JBoss nie zakoczy wdraania przykadowego komponentu w czasie, na jaki pozwala klient. Problem ten jest spowodowany
dugim czasem inicjalizacji generatora liczb losowych uywanego przez gniazda SSL
serwera. W razie wystpienia tego problemu wystarczy ponownie uruchomi przykad
lub zwikszy czas oczekiwania podany w pliku build.xml w katalogu zawierajcego
przykady do rozdziau 8.
Konfiguracja serwera JBoss

dziaajcego za firewallem
JBoss posiada wiele usug korzystajcych z gniazd, ktre wymagaj utworzenia portw serwera. W tym podrozdziale przedstawione zostay usugi uywajce portw,
ktre najprawdopodobniej trzeba bdzie skonfigurowa w przypadku korzystania z serwera JBoss dziaajcego za firewallem. W tabeli 8.2 przedstawione zostay numery
404
portw, ich typ oraz uywajce ich usugi, przy czym zamieszczone informacje dotycz
standardowej konfiguracji JBoss. Z kolei tabela 8.3 przedstawia analogiczne informacje dla usug podanych w konfiguracji all.
Tabela 8.2. Porty uywane w konfiguracji domylnej
Numer
Typ
Usuga
1099
TCP
org.jboss.naming.NamingService
1098
TCP
org.jboss.naming.NamingService
4444
TCP
org.jboss.invocation.jrmp.server.JRMPInvoker
4445
TCP
org.jboss.invocation.pooled.server.PooledInvoker
8009
TCP
org.jboss.web.tomcat.tc4.EnbeddedTomcatService
8080
TCP
org.jboss.web.tomcat.tc4.EnbeddedTomcatService
8083
TCP
org.jboss.web.WebService
8093
TCP
org.jboss.mq.il.uil2.UILServerILService
Tabela 8.3. Porty uywane w konfiguracji o nazwie all

Numer
Typ
Usuga
1100
TCP
org.jboss.ha.jndi.HANamingService
0a
TCP
1102
UDP
1161
UDP
org.jboss.jmx.adaptor.snmp.agent.SnmpAgentService
1162
UDP
org.jboss.jmx.adaptor.snmp.trapd.TrapdService
3528
TCP
org.jboss.invocation.iiop.IIOPInvoker
45566b
UDP
org.jboss.ha.framework.server.ClusterPartition
a aktualnie jest to port anonimowy, lecz mona go poda przy uyciu atrybutu RmiPort.
b istniej dwa dodatkowe porty anonimowe UDP, okreli jednak mona tylko jeden z nich;
suy do tego celu atrybut rcv_port.
Zabezpieczanie serwera JBoss

JBoss posiada kilka punktw dostpu administracyjnego, ktre naley odpowiednio zabezpieczy lub usun, by uniemoliwi nieautoryzowany dostp do serwera produkcyjnego. W kolejnych punktach zostay opisane rne usugi administracyjne oraz
sposoby ich ochrony.
405
Usuga jmx-console.war
Usuga jmx-console.war, ktr mona znale w gwnym katalogu wdroeniowym
serwera, generuje strony HTML dostarczajce informacji o stanie jdra serwera. A zatem usuga ta zapewnia dostp do wszelkich operacji administracyjnych, takich jak
zamykanie serwera, zatrzymywanie usug, wdraanie nowych usug i tak dalej. Usug
t naley zabezpieczy jak kad aplikacj sieciow bd te cakowicie wyczy.
Usuga web-console.war
Usuga web-console.war, ktr mona znale w katalogu deploy/management, jest
kolejn aplikacj sieciow zapewniajc dostp do jdra serwera JMX. Wykorzystuje
ona kombinacj apletw oraz stron HTML i zapewnia porwnywalne moliwoci
administracyjne co usuga jmx-console.war. Wanie z tego wzgldu naley j zabezpieczy lub usun. W archiwum web-console.war mona znale zapisane w komentarzach szablony podstawowych zabezpiecze (w pliku WEB-INF/web.xml) oraz konfiguracj dziedziny bezpieczestwa (w pliku WEB-INF/jboss-web.xml).
Usuga http-invoker.sar
Plik http-invoker.sar umieszczony w katalogu wdroeniowym zawiera usug zapewniajc dostp do komponentw EJB i usugi Naming JNDI za pomoc RMI i HTTP.
Usuga ta zawiera serwlet, ktry przetwarza wiadomoci generowane przez szeregowane obiekty org.jboss.invocation.Invocation reprezentujce wywoania, ktry powinny zosta przekazane do MBeanServer. W efekcie daje ona moliwo dostpu za
porednictwem protokou HTTP do komponentw MBean wspomagajcych dziaanie
odczonej usugi wywoujcej RMI/JRMP, gdy istnieje moliwo okrelenia postaci
odpowiedniego dania HTTP POST. Aby uchroni si przed t moliwoci dostpu,
naleaoby zabezpieczy serwlet JMXInvokerServlet, zapisujc niezbdne informacje
konfiguracyjne w pliku http-invokier.sar/invoker.war/WEB-INF/web.xml. Poniewa
domylnie jest ju zdefiniowane bezpieczne odwzorowanie dla cieki /restricted/
JMXInvokerServlet, a zatem, aby go zastosowa, wystarczy usun inne cieki oraz
skonfigurowa domen bezpieczestwa http-invokier w pliku http-invoker.sar/invoker.
war/WEB-INF.xml.
Usuga jmx-invoker-adaptor-server.sar
Plik jmx-invoker-adaptor-server.sar zawiera usug, ktra uywajc wydzielonej usugi
wywoujcej RMI/JRMP zapewnia dostp do interfejsu MBeanServer przy uyciu interfejsu zgodnego z RMI. Obecnie jedynym sposobem zabezpieczenia tej usugi mogoby by zmiana uywanych protokow na RMI i HTTP oraz zabezpieczenie usugi
http-invoker.sar w sposb opisany w poprzednim punkcie. W przyszoci usuga ta
zostanie uruchomiona jako komponent XMBean dysponujcy odpowiedzialnym za bezpieczestwo obiektem wywoujcym obsugujcym kontrol dostpu bazujc na rolach.

JBoss 4.0. Podręcznik Administratora

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

JBoss 4.0. Podręcznik Administratora

Uploaded by

Copyright:

Available Formats

IDZ DO

JBoss 4.0. Podrcznik

JBoss 4.0. Podrcznik administratora

Rozdzia 2. Jdro serwera JBoss ....................................................................... 45

Rozdzia 3. Obsuga nazw ............................................................................... 155

Rozdzia 4. Transakcje ................................................................................... 193

Rozdzia 5. Komponenty EJB w JBoss ............................................................. 201

JBoss 4.0. Podrcznik administratora

Rozdzia 6. Usuga komunikatw JMS w JBoss ................................................ 253

Rozdzia 7. JCA w JBoss ................................................................................. 295

Rozdzia 8. Bezpieczestwo ............................................................................ 323

Rozdzia 9. Aplikacje sieciowe ........................................................................ 407

Rozdzia 10. Inne usugi MBean ........................................................................ 431

Rozdzia 11. Mechanizm CMP .......................................................................... 443

JBoss 4.0. Podrcznik administratora

Rozdzia 12. Usugi sieciowe ............................................................................ 527

Rozdzia 13. Hibernate ..................................................................................... 543

Rozdzia 14. Obsuga programowania aspektowego (AOP) ................................. 551

Dodatek A Publiczna licencja GNU ................................................................. 573

Deklaratywny model obsugi

JBoss 4.0. Podrcznik administratora

Zabezpieczenie aplikacji J2EE zaley od konfiguracji wymaga, a ta znajduje si

Referencje element security-role-ref

Sposb wykorzystania elementu security-role-ref w pliku web.xml demonstruje listing 8.2

Tosamo element security-identity

JBoss 4.0. Podrcznik administratora

Role element security-role

Na listingu 8.5 widzimy element security-role uyty w deskryptorze web.xml.

JBoss 4.0. Podrcznik administratora

Uprawnienia wywoywania metod

Kady element method-permission posiada jeden lub wiele elementw zagniedonych

Istniej trzy dopuszczalne sposoby deklaracji elementu method:

metody interfejsu domowego i zdalnego danego komponentu EJB:

Sposb drugi stosujemy, gdy chcemy wskaza metod o podanej nazwie

wchodzc w skad interfejsu domowego lub zdalnego danego komponentu EJB:

metod nawet wwczas, gdy jej nazwa jest przeciona.

Wskazana metoda musi by skadnikiem interfejsu domowego lub zdalnego

JBoss 4.0. Podrcznik administratora

Uprawnienia dotyczce aplikacji sieciowych

Tre, ktra ma by chroniona, deklarujemy za pomoc jednego lub wielu elementw

JBoss 4.0. Podrcznik administratora

Obsuga bezpieczestwa deklaratywnego

JBoss 4.0. Podrcznik administratora

Czym jest JAAS?

Podstawowe klasy JAAS

Klasy zwizane z uwierzytelnianiem:

Klasy Subject i Principal

zaadowa. Przy braku wskazanej konfiguracji domylnie uyta zostanie

zwraca informacje wymagane w procesie uwierzytelnienia. Parametrem

JBoss 4.0. Podrcznik administratora

moemy usun wszystkie zwizane z nim tosamoci i inne stowarzyszone

CallbackHandler handler = new MyHandler();

} else if (callbacks[i] instanceof PasswordCallback) {

Istnieje moliwo stworzenia wasnej implementacji interfejsu LoginModule. Dziki

korzystajc z ich bezparametrowego konstruktora.

Moe ona na przykad wywietli okienko suce do wprowadzenia nazwy

JBoss 4.0. Podrcznik administratora

Niepowodzenie w fazie pierwszej take wiza si bdzie z wywoaniem

logowania powinien by zignorowany.

informacji dotyczcych procesu uwierzytelnienia, tym razem jednak dzieje

Model bezpieczestwa serwera JBoss

Klasy zaznaczone na rysunku 8.8 kolorem szarym to interfejsy warstwy bezpieczestwa,

JBoss 4.0. Podrcznik administratora