Blog Technologiczny ATENA » JBoss

JBoss + LDAP

Michał Łaguna — Thu, 06 Oct 2011 12:25:09 +0000

Jak skonfigurować w JBossie uwierzytelnianie i autoryzację opartą o LDAP ?

Na początek przykładowa aplikacja

Na potrzeby testów stwórzmy sobie prościutką aplikację i umieśćmy ją na JBossie.

Najprościej będzie użyć do tego celu mechanizmu archetypów Mavena:

mvn archetype:generate
wybierzmy webapp-jee5
wybierzmy wersję 1.0
wskażmy groupId – np. pl.atena
wskażmy artifactId – np. ldap-integration
wskażmy version – np. 1.0-SNAPSHOT
wskażmy pakiet – np. pl.atena.ldap

Po zatwierdzeniu powinniśmy mieć gotowy do deployu projekt.

Wystarczy go zbudować

mvn clean package

i skopiować do katalogu JBOSS/server/default/deploy

Po uruchomieniu serwera i wejściu na stronę http://localhost:8080/ldap-integration powinniśmy zobaczyć „Hello World”.

Konfiguracja modułu uwierzytelniania w JBossie

Kolejnym krokiem będzie konfiguracja uwierzytelniania w JBossie. W tym celu edytujemy plik JBOSS/Server/default/login-config.xml i dodajemy w nim nową politykę bezpieczeństwa, którą nazwiemy ldap:


  
    
      ldap://serwerLdap:389
      ATENA\ldapUser
      password

      CN=Users,DC=companyName,DC=com
      (sAMAccountName={0})

      OU=Groups,DC=companyName,DC=com
      true
      member
      (member={1})
      CN

      2
      SUBTREE_SCOPE

      false

Wyjaśnienie najważniejszych parametrów:

login-module – wskazanie modułu uwierzytelniania – dla samego uwierzytelniania możemy użyć LdapLoginModule; jeśli chcemy użyć również autoryzacji opartej o LDAP musimy użyć LdapExtLoginModule
java.naming.provider.url – namiary na kontroler domeny
bindDN – nazwa użytkownika z uprawnieniami do wykonywania zapytań w LDAPie
bindCredential – hasło użytkownika
baseCtxDN – ścieżka do wyszukiwania użytkownika
baseFilter – filtr służący do wyszukania uwierzytelnianego użytkownika
rolesCtxDN – ścieżka do wyszukiwania roli
roleFilter – filtr służący do wyszukania roli użytkownika
roleAttributeID – wskazanie na miejsce w ścieżce gdzie będzie nazwa roli
roleRecursion – głębokość wyszukiwania roli
searchScope – zasięg wyszukiwania (OBJECT_SCOPE, ONELEVEL_SCOPE, SUBTREE_SCOPE)
allowEmptyPasswords – flaga wskazująca, czy puste hasła powinny być przekazywane do serwera LDAPa (niektóre serwery LDAP traktują puste hasło jako zalogowanie anonimowe)

Pełna lista parametrów dla modułu LdapExtLoginModeule dostępna jest pod adresem:

http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/4.2/html/Server_Configuration_Guide/Using_JBoss_Login_Modules-LdapExtLoginModule.html

Podpięcie uwierzytelniania do aplikacji

Ostatnim krokiem jest podpięcie dodanej polityki do naszej aplikacji i zabezpieczenie dostępu do pewnych zasobów w aplikacji. W tym celu dodajemy w katalogu src/main/webapp/WEB-INF/ plik jboss-web.xml o następującej treści:


  java:/jaas/ldap

Następnie zabezpieczamy dostęp do aplikacji w pliku web.xml:


  Archetype Created Web Application
  
    
      LDAP Restricted Zone
      /*
    
    
      administrator
    
    
    
      BASIC
      LDAP Restricted Zone
    
    
      administrator

Gdy ponownie wejdziemy na stronę naszej aplikacji (http://localhost:8080/ldap-integration) powinniśmy zostać zapytani o login i hasło użytkownika. Po podaniu domenowego loginu i hasła powinniśmy ponownie zobaczyć nasze ‘Hello World’ – pod warunkiem, że jesteśmy w LDAPie przypisani do grupy administrator.

PRAKTYCZNY ENVERS

Mateusz Mrozewski — Fri, 20 Aug 2010 07:00:10 +0000

Envers jest dodatkiem do Hibernate’a pozwalającym na automatyczne zapisywanie historii zmian encji (audytu). Envers używa pojęcia rewizji – co oznacza, że każda zmiana dowolnej (audytowalnej) encji tworzy nową rewizję. Nowy rekord jest zapisany do tabeli, a na podstawie starego zostaje utworzona rewizja i zapisana do dodatkowej tabeli wraz z poprzednimi wartościami.

Konfiguracja

W ramach podstawowej niezbędnej konfiguracji należy dodać następujące właściwości do pliku persistence.xml lub hibernate.cfg.xml:

Konfigurujemy w ten sposób listenery , które sprawdzają, czy zmieniły się jakieś audytowalne encje i czy należy zachować historię zmian tych encji.

Kolejnym krokiem jest już oznaczenie encji adnotacją @Audited. Jeśli adnotację umieścimy na poziomie klasy, wszystkie pola będą wersjonowane. Możemy również adnotację umieścić na poziomie pól klasy, aby wersjonować tylko wybrane.

Przykład użycia

Po umieszczeniu konfiguracji opisanej w kroku wyżej użycie Envers’a sprowadza się do dodania odpowiednich adnotacji.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@Entity
@Audited
public class Item {
@Id
private int id;

private String name;

public int getId() {
return id;
}

public void setId(int id) {
this.id = id;
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}
}

I to tak naprawdę wszystko z rzeczy specyficznych dla Envers. Użycie encji w innym zakresie jest tak standardowe, jak w przypadku JPA lub Hibernate i w zasadzie niczym się od nich nie różni.

Przechowywanie rewizji

Dla każdej adnotowanej encji zostanie utworzona dodatkowa tabela przechowująca audyt. Dla naszej encji z podanego przykładu powstanie podstawowa tabela:

1
2
3
4
5

CREATE TABLE ITEM
(
ID decimal(10) PRIMARY KEY NOT NULL,
NAME varchar2(1020)
);

Oraz dodatkowa tabela do przechowywania audytu:

1
2
3
4
5
6
7
8

CREATE TABLE ITEM_AUD
(
ID decimal(10) NOT NULL,
REV decimal(10) NOT NULL,
REVTYPE decimal(3),
NAME varchar2(1020),
CONSTRAINT SYS_C006187 PRIMARY KEY (ID,REV)
);

Dodatkowo doszły nam następujące pola:

REV – oznacza numer rewizji;
REVTYPE – typ zmiany; możliwe wartości: 0 – wstawienie rekordu, 1 – modyfikacja rekordu, 2 – usunięcie rekordu.

Najnowszy rekord w tabeli audytu będzie miał wartości o jedną wersję wstecz względem wartości w aktualnej tabeli. Jeśli natomiast rekord zostanie usunięty, nie znajdziemy go już w tabeli podstawowej, a najświeższy wpis będzie miał wartości ustawione na i typ rewizji 2.

Numery rewizji są wspólne dla wszystkich encji. Oznacza to, że jeśli najpierw zmienimy encję A, otrzyma ona rewizję 1, dopiero potem zmienimy encję B, która otrzyma rewizję 2 (oczywiście obie będą posiadały oddzielne tabele audytu).

Encja rewizji i zapis dodatkowych danych

Oprócz zapisywania historii zmian danej encji możemy dla każdej rewizji zapisać dodatkowe informacje. Służy do tego encja rewizji – jest to standardowa encja z dodatkową adnotacją oraz dodatkowymi polami, jakie chcemy zapisać. Przykładowo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Entity
@RevisionEntity(MyRevisionListener.class)
public class MyRevisionEntity extends DefaultRevisionEntity {
private static final long serialVersionUID = -78999006241889798L;
private String username;

public String getUsername() {
return username;
}

public void setUsername(String username) {
this.username = username;
}
}

Klasa DefaultRevisionEntity jest dostarczana wraz z Envers i deklaruje dwa podstawowe pola: id oraz timestamp. Do tego możemy dołożyć dodatkowe informacje, które chcemy zapisać, np. nazwę użytkownika. Wykonuje się to w listenerze wskazanym przez adnotację @RevisionEntity:

1
2
3
4
5
6
7
8

public class MyRevisionListener implements RevisionListener {

public void newRevision(Object revisionEntity) {
MyRevisionEntity entity = (MyRevisionEntity) revisionEntity;
entity.setUsername("NAZWA UŻYTKOWNIKA");
}

}

Dla przykładowej encji rewizji zostanie utworzona następująca tabela:

1
2
3
4
5
6

CREATE TABLE MYREVISIONENTITY
(
ID decimal(10) PRIMARY KEY NOT NULL,
TIMESTAMP decimal(19) NOT NULL,
USERNAME varchar2(1020)
);

Teraz przy utworzeniu nowej rewizji dowolnej audytowanej encji zostanie utworzony nowy wpis w tej tabeli z danymi uzupełnionymi według naszego listenera.

Odpytywanie o rewizje

Envers dostarcza klasy użytkowe pozwalające na odpytywanie o stan rewizji poszczególnych encji. Klasa AuditReaderFactory pozwala nam na pobranie instancji AuditReader w zależności od tego, czy operujemy na EntityManager z JPA czy też na Session z Hibernate.

AuditReader pozwala na budowanie zapytań implementujących interfejs AuditReader. Służy on do budowania zapytań w sposób podobny jak w przypadku Hibernate Criteria. Pytać możemy na dwa sposoby:

o encję w konkretnej rewizji,
o rewizje, w których encje się zmieniły.

Przykład zapytania o konkretną rewizję:

1
2
3
4
5
6
7

int revision = 1;
AuditQuery query = getAuditReader().createQuery().forEntitiesAtRevision(Item.class, revision);

List items = query.addOrder(AuditEntity.property("name").desc())
.setFirstResult(4)
.setMaxResults(2)
.getResultList();

Przykład zapytania o rewizje, w których zmieniała się encja:

1
2
3
4
5
6

int revision = 1;
Number revision = (Number) getAuditReader().createQuery()
.forRevisionsOfEntity(Item.class, false, true)
.setProjection(AuditEntity.revisionNumber().min())
.add(AuditEntity.id().eq(entityId))
.getSingleResult();

Wnioski

Jak widać, Envers pozwala na łatwe wdrożenie historii zmian bez specjalnego nakładu pracy i praktycznie transparentnie dla istniejącego modelu. Warto też wspomnieć, że Envers stał się już częścią dystrybucji Hibernate’a (od wersji 3.5), co dodatkowo świadczy o jego użyteczności i jakości.

Źródła

Strona główna projektu: http://jboss.org/envers
Dokumentacja: http://docs.jboss.org/envers/docs/index.html

JSR-303 – przepis na fasolkę. Bardzo dobrą poniekąd. Cz. 1

Daniel Ramotowski — Thu, 11 Feb 2010 09:21:27 +0000

Finalna wersja specyfikacji JSR-303: Bean Validation ukazała się światu pod koniec ubiegłego roku (2009). Jest to kolejny przysmak a’la carte z renomowanej kuchni Gavin’a King’a i spółki, który doczekał się formalnej specyfikacji. Zatem – delektujmy się przez chwilę…

Dla osób niewtajemniczonych wyjaśniam, że mam na myśli produkt hibernate-validator, który jest protoplastą specyfikacji.
Wraz z nią otrzymaliśmy jej implementację referencyjną w postaci produktu hibernate-validator w wersji 4.
Świadomy tego, że bezapelacyjnie każdego ta historia urzekła przejdę do konkretów.
Dlaczego w ogóle o tym piszę? istnieje co najmniej kilka powodów:

Jest to nowy standard w ramach Javy.
Będzie wchodził w skład JEE 6.
Bardzo łatwo się go używa – również na platformie SAP NetWeaver.
Posiada nowe rozbudowane API oraz nowe możliwości rozszerzeń (np. tzw. „composite constraints”).
W sposób przezroczysty integruje się z już posiadanym kodem.

Ponieważ jest to artykuł subiektywny, nie zamierzam w nim wymieniać wszystkich właściwości oraz różnic w specyfikacji JSR 303 w stosunku do starego hibernate-validator’a. Ze szczegółami można zawsze zapoznać się pobierając specyfikację ze stron Java Community Process.

Moim zdaniem bardzo istotna jest rozbudowa specyfikacji o możliwość definiowania mechanizmów walidacji za pomocą deskryptorów XML. Być może niektórzy czytelnicy posądzą mnie tutaj o herezję, ponieważ dziesiątki deskryptorów dostępnych w JEE to swoiste „małe piekiełko”. W przypadku walidatora jest to bardzo dobry pomysł o czym świadczą silne argumenty:

Deskryptory pozwalają na zastosowanie walidacji w beanach dostarczanych w postaci bibliotek,
Definicje w deskryptorach uniezależniają walidowane komponenty od API walidatora oraz własnych walidatorów w formie rozszerzeń.

Poniżej przedstawiam przykład kodu z zastosowaniem adnotacji oraz odpowiednika z zastosowaniem deskryptora xml.

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
35
36
37
38
39
40
41
42
43

// Person.java
package test.beans;
import javax.validation.constraints.NotNull;
import javax.validation.Size;
import javax.validation.constraints.Past;
import java.util.List;
import java.util.Date;
import javax.validation.Valid;

public class Person {

// wymuszenie wartości różnej niż null
@NotNull(message="Imię nie może być puste")
private String name;

// wymuszenie wartości różnej niż null
@NotNull(message="Nazwisko nie może być puste")
private String surname;

// wymuszamy datę przeszłą w stosunku do czasu systemowego
@Past(message="Należy podać datę przeszłą")
private Date birthDate;

// oczekiwanie, że w kolekcji będzie co najmniej jeden element
@Size(min=1,message="Należy podać co najmniej jeden adres")
@Valid // wskazanie aby implementacja wykonała również walidację adresów
private List<Address> adrList;
(...)
}
----------------------------------------------------------
// Address.java
package test.beans;
import javax.validation.constraints.NotNull;

public class Address {

// wymuszenie wartości różnej niż null
@NotNull(message="Miasto nie może być puste")
private String city;

(...)
}

Stan analogiczny do powyższego kodu możemy uzyskać za pomocą następujących definicji w deskryptorze xml:

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
35
36
37
38
39
40
41
42
43

version="1.0" encoding="UTF-8"?>

xmlns="http://jboss.org/xml/ns/javax/validation/mapping"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd">

test.beans>

class="Person" ignore-annotations="true">
name="name">
annotation="javax.validation.constraints.NotNull">
>Imię nie może być puste>
>
>
name="surname">
annotation="javax.validation.constraints.NotNull">
>Nazwisko nie może być puste>
>
>
name="birthDate">
annotation="javax.validation.constraints.Past">
>Należy podać datę przeszłą>
>
>
name="adrList">
annotation="javax.validation.constraints.Size">
>Należy podać co najmniej jeden adres>
name="min">1>
>
/>
>
>

class="Address" ignore-annotations="true">
name="city">
annotation="javax.validation.constraints.NotNull">
>Miasto nie może być puste>
>
>
>

>

Nie jest trudno wywnioskować, że wszystkie ograniczenia zdefiniowane w kodzie źródłowym mają swoje odpowiedniki w deskryptorze. Aby powyższe przykłady uruchomić, konieczne jest jeszcze skonfigurowanie całego „silnika” walidacji.
Konfigurację realizuje się przez zamieszczenie w katalogu META-INF pliku o nazwie validation.xml, który jest deskryptorem konfiguracji JSR-303.
Oto przykład pliku:

1
2
3
4
5
6
7
8
9

version="1.0" encoding="UTF-8"?>

xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.0.xsd">

org.hibernate.validator.HibernateValidator>

META-INF/sample-constraints.xml>
>

W powyższym pliku określono następujące właściwości silnika:

Default-provider wskazuje dostawcę implementacji JSR-303, którym jest oczywiście hibernate validator
Constraint-mapping wskazuje na dodatkowy deskryptor xml z definicją ograniczeń, można zdefiniować wiele plików z definicją ograniczeń

Na deser pozostał mi jeszcze prościutki przykład uruchomienia walidacji w kodzie z zastosowaniem poprzednich przykładów.
Oto on:

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

// ValidationTest.java
package test.beans;
import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.ValidatorFactory;

public class ValidationTest {

public static void main(String[] argv) {
ValidationTest vt = new ValidationTest();
Person p = new Person();
p.name= "John";
t.validateBean(p);
return;
}

public void validateBean(Person p) {
ValidatorFactory vf = Validation.buildDefaultValidatorFactory();
Set<ConstraintViolation> violationSet = vf.getValidator().validate(p);
for(ConstraintViolation cv : violationSet ) {
System.out.println(cv.getMessage());
}
return;
}

}

Smacznej walidacji