Pakiet portalowy Joshua wykorzystuje interfejs narzêdziowy do zarz±dzania u¿ytkownikami portalu. Interfejs ten pozwala na zarz±dzanie u¿ytkownikami, których dane sk³adowane s± w relacyjnej bazie danych lub bazie danych LDAP. Portal mo¿e korzystaæ z dowolnej z tych baz danych przechowuj±cych dane o u¿ytkownikach.

Dane u¿ytkowników portalu, w ¶wietle ustawy z dnia 29 sierpnia 1997 o Ochronie danych osobowych (Dz.U. 1997 Nr 133 poz. 883), nale¿y traktowaæ jako dane osobowe. Podlegaj± one prawnej ochronie przewidzianej w powo³anej ustawie. Pakiet portalowy Joshua zosta³ dostosowany w celu zapewnienia w³a¶ciwej ochrony danych osobowych u¿ytkowników portalu. Zadanie to obejmowa³o wydzielenie i separacjê danych wra¿liwych od innych danych portalu i przeniesienie ich na wydzielone konto bazodanowe oraz zastosowanie w³a¶ciwej ochrony przy przesy³aniu tych danych.

Ze wzglêdu na to, ¿e podczas prac rozwojowych nad portalem istnieje konieczno¶æ utworzenia ¶rodowiska testowego, konieczne jest zapewnienie mo¿liwo¶ci tworzenia kopii bazy danych u¿ytkowników portalu. Wykonanie takiej kopii konieczne jest tak¿e w procesie migracji pomiêdzy ró¿nymi bazami danych.

Projektowana aplikacja ma za zadanie zautomatyzowaæ proces przenoszenia danych pomiêdzy bazami danych, a tak¿e pozwoliæ przeprowadziæ proces anonimizacji danych, maj±cy na celu uniemo¿liwienie identyfikacji poszczególnych u¿ytkowników portalu. Anonimizacja danych ma kluczowe znaczenie w przypadku tworzenia bazy danych u¿ytkowników portalu, która ma byæ wykorzystana w ¶rodowisku testowym. Pozwala ona usun±æ cechê zbioru danych osobowych ze zbioru danych u¿ytkowników portalu testowego i ograniczyæ jednocze¶nie liczbê osób maj±cych dostêp do chronionych danych.

2 ¦rodowisko dzia³ania aplikacji

Aplikacja do przenoszenia danych u¿ytkowników portalu pracuj±cego w oparciu o pakiet portalowy Joshua pozwola przenosiæ dane pomiêdzy relacyjnymi bazami danych i bazami danych LDAP.

¦rodowisko portalowe Joshua dostarcza zunifikowanego interfejsu zarz±dzania u¿ytkownikami pozwalaj±cego na sk³adowanie danych u¿ytkowników w ró¿nych bazach danych. Projektowana aplikacja wykorzystuje ten interfejs w celu wykonania kopii bazy danych u¿ytkowników.

Interfejs do zarz±dzania u¿ytkownikami zdefiniowany zosta³ jako zbiór operacji, które mog± byæ wykonane na danych opisuj±cych u¿ytkowników. Interfejs ten posiada obecnie dwie implementacje obejmuj±ce wspó³pracê z relacyjn± baz± danych i baz± danych LDAP. W dokumencie "Projekt przeniesienia informacji o u¿ytkownikach aplikacji portalowej z relacyjnej bazy danych (Oracle) do bazy LDAP-owej" opisano schematy danych, które s³u¿± do sk³adowania danych o u¿ytkownikach. W punkcie 4 zaprezentowano skrypty pozwalaj±ce utworzyæ schematy odpowiednich baz danych.

Projektowana aplikacja abstrahuje od reprezentacji danych specyficznej dla wybranego rozwi±zania sk³adowania danych i operuje na reprezentacji obiektowej zdefiniowanej w interfejsie zarz±dzania u¿ytkownikami ¶rodowiska portalowego Joshua. Mo¿liwa jest dziêki temu jej rozbudowa w przysz³o¶ci i dostosowanie do wspó³pracy z kolejnym ¼ród³em danych. Zastosowanie takiego rozwi±zania znacznie upraszcza budowê aplikacji oraz zapewnia jej niezale¿no¶æ od ewentualnych przysz³ych zmian w atrybutach s³u¿±cych do opisywania u¿ytkowników w pakiecie portalowym Joshua.

Ka¿dy u¿ytkownik ¶rodowiska portalowego Joshua opisany jest zbiorem atrybutów, mo¿e posiadaæ w³asno¶ci i przynale¿eæ do wielu grup u¿ytkowników. W pakiecie portalowym Joshua u¿ytkownik reprezentowany jest przez obiekt o nastêpuj±cych atrybutach:

- id - numeryczny identyfikator u¿ytkownika,

- login - login u¿ytkownika w portalu,

- imiê - imiê u¿ytkownika,

- nazwisko - nazwisko u¿ytkownika,

- e-mail - adres e-mail,

- mobile - numer telefonu komórkowego,

- isAdmin - czy u¿ytkownik mo¿e logowaæ siê w portalu administracyjnym,

- modUser - kto modyfikowa³ dane u¿ytkownika,

- modDate - data ostatniej modyfikacji.

U¿ytkownik portalu mo¿e posiadaæ dowoln± liczbê w³asno¶ci o unikalnych nazwach. W³asno¶ci s± wykorzystywane do przechowywania specyficznych informacji o u¿ytkowniku. Ka¿da z us³ug portalu mo¿e sk³adowaæ specyficzne informacje o u¿ytkowniku w jego w³asno¶ciach. Mechanizm ten u¿ywany jest zwykle do wspó³dzielenia cech u¿ytkownika pomiêdzy us³ugami portalu.

W pakiecie portalowym Joshua istnieje mo¿liwo¶æ definiowania grup u¿ytkowników. Grupa u¿ytkowników jest bytem abstrakcyjnym s³u¿±cym do agregowania u¿ytkowników w celu nadawania im wspólnych uprawnieñ do us³ug i zasobów. Ka¿dy u¿ytkownik mo¿e nale¿eæ do wielu grup u¿ytkowników.

3 Funkcjonalno¶æ aplikacji

Projektowana aplikacja pozwala:

- wykorzystaæ dowolne ¼ród³o danych (bazê relacyjn±, bazê LDAP)

- wykonaæ kopiê bazy danych u¿ytkowników do dowolnej docelowej bazy danych (baza relacyjna, baza LDAP)

- poddaæ anonimizacji kopiowane dane.

Dla poprawnego wykonania operacji kopiowania bazy danych u¿ytkowników aplikacja wymaga:

- dostarczenia ¼ród³a danych które maj± byæ kopiowane - ¼ród³o to musi byæ dostêpne przez jedn± z implementacji zunifikowanego interfejsu zarz±dzania u¿ytkownikami pakietu portalowego Joshua.

- dostarczenia docelowej bazy danych (ze zdefiniowanym schematem przechowywania danych) - do której kopiowane bêd± dane. Baza ta musi byæ dostêpna przez jedn± z implementacji zunifikowanego interfejsu zarz±dzania u¿ytkownikami pakietu portalowego Joshua.

- zaprzestania, na czas kopiowania danych, modyfikowania ¼ród³owej bazy u¿ytkowników - dla zapewnienia spójno¶ci przenoszonych danych.

3.1 Kopiowanie danych

Proces kopiowania bazy u¿ytkowników realizowany jest zgodnie z przedstawionym poni¿ej algorytmem.

1. Pobierz wszystkie grupy u¿ytkowników ze ¼ród³owej bazy danych u¿ytkowników i utwórz je w docelowej bazie danych.

2. Pobierz nie wiêcej ni¿ packageSize kolejnych rekordów opisuj±cych u¿ytkowników ze ¼ród³owej bazy danych.

3. Dla ka¿dego u¿ytkownika z pobranego zbioru rekordów:

a. Zapisz rekord opisuj±cy u¿ytkownika do docelowej bazy danych

b. Pobierz w³asno¶ci, które posiada u¿ytkownik i zapisz w docelowej bazie danych.

c. Pobierz listê grup u¿ytkowników, do których nale¿y kopiowany u¿ytkownik i dodaj go do tych grup w docelowej bazie danych

4. Je¿eli pozostali jeszcze u¿ytkownicy, którzy maj± byæ kopiowani przejd¼ do pkt.2

Algorytm ten zapewnia przeniesienie wszystkich danych opisuj±cych u¿ytkowników.

Proces kopiowania danych podlega konfiguracji za pomoc± nastêpuj±cych parametrów:

probeSize - liczba u¿ytkowników do kopiowania. Je¶li jest mniejsza lub równa 0, to kopiowane s± wszyscy u¿ytkownicy. Parametr pozwala tworzyæ mniejsze (testowe) zbiory danych.

packageSize - liczba rekordów opisuj±cych u¿ytkowników, która ma byæ jednorazowo pobierana i kopiowana do docelowej bazy danych

3.2 Anonimizacja danych

Projektowana aplikacja zapewnia mo¿liwo¶æ anonimizacji przenoszonych danych u¿ytkowników. Anonimizacja danych realizowana jest zgodnie z nastêpuj±cym algorytmem:

1. Pobierz wszystkie grupy u¿ytkowników ze ¼ród³owej bazy danych u¿ytkowników i utwórz je w docelowej bazie danych.

2. Pobierz packageSize kolejnych rekordów opisuj±cych u¿ytkowników ze ¼ród³owej bazy danych.

3. Pobierz packageSize zbiorów w³asno¶ci u¿ytkowników opisywanych przez rekordy pobrane w kroku 2 ze ¼ród³owej bazy danych.

4. Dla ka¿dej podlegaj±cej anonimizacji cechy u¿ytkownika:

a. Okre¶l wektor przypadkowych zamienników PZ tj. wektor packageSize u³o¿onych w losowej kolejno¶ci identyfikatorów rekordów pobranych w kroku 2.

b. dla ka¿dego rekordu o identyfikatorze przechowywanym na parzystej pozycji (n) w wektorze PZ - zamieñ warto¶ci cechy miêdzy rekordem a jego nastêpnikiem (rozumianym jako rekord o identyfikatorze przechowywanym na pozycji: (n+1) modulo packageSize w wektorze PZ) z okre¶lonym prawdopodobieñstwem.

5. Okre¶l nowy wektor przypadkowych zamienników PZW.

6. Dla co drugiej w³asno¶ci ka¿dego u¿ytkownika o identyfikatorze przechowywanym na parzystej pozycji (n) w wektorze PZW oraz jego nastêpnika (rozumianego jako rekord o identyfikatorze przechowywanym na pozycji: (n+1) modulo packageSize w wektorze PZW):

a. je¶li istnieje odpowiednik w³asno¶ci u zamiennika - zamieñ warto¶ci w³asno¶ci (z prawdopodobieñstwem PropChangeProp);

b. w przeciwnym wypadku - przeka¿ w³asno¶æ zamiennikowi (z prawdopodobieñstwem PropReplaceProp).

7. Powtórz kroki 5 i 6 dla pozosta³ej po³owy w³asno¶ci u¿ytkowników przetwarzanego zbioru.

8. Dla ka¿dego u¿ytkownika z przetwarzanego wektora:

a. Zapisz w docelowej bazie danych rekord opisuj±cy u¿ytkownika po anonimizacji danych;

b. Zapisz w docelowej bazie danych anonimizowane zbiory w³asno¶ci u¿ytkownika

c. Pobierz listê grup u¿ytkowników, do których nale¿y i dodaj go do tych grup w docelowej bazie danych.

9. Je¿eli pozostali jeszcze u¿ytkownicy, którzy maj± byæ kopiowani przejd¼ do pkt.2

Algorytm (przy domy¶lnych warto¶ciach parametrów konfiguracyjnych) zapewnia:

- losowe wymieszanie odpowiednich warto¶ci cech u¿ytkowników przy niezmienno¶ci cech: identyfikator i has³o;

- losowe wymieszanie w³asno¶ci u¿ytkowników;

- niezmienno¶æ przynale¿no¶ci u¿ytkowników do grup u¿ytkowników.

Proces anonimizacji mo¿na konfigurowaæ okre¶laj±c nastêpuj±ce parametry:

FNChangeProb - prawdopodobieñstwo zamiany warto¶ci cechy FirstName u¿ytkownika.

LNChange Prob - prawdopodobieñstwo zamiany warto¶ci cechy LastName u¿ytkownika.

EmailChangeProb - prawdopodobieñstwo zamiany warto¶ci cechy E-mail u¿ytkownika.

MobileChangeProb - prawdopodobieñstwo zamiany warto¶ci cechy Mobile u¿ytkownika.

PropChangeProb - prawdopodobieñstwo zamiany warto¶ci jednej z w³asno¶ci u¿ytkownika.

PropReplaceProb - prawdopodobieñstwo utraty w³asno¶ci (oraz jej warto¶ci) przez u¿ytkownika na rzecz innego u¿ytkownika.

Parametry przyjmuj± warto¶ci z przedzia³u [0 - 1]. Warto¶ci± domy¶ln± jest 1. Oznacza ona pewno¶æ ka¿dorazowej wymiany warto¶ci cechy lub w³asno¶ci. Wymianie cechy lub w³asno¶ci mo¿na zapobiec poprzez ustawienie odpowiedniego parametru na warto¶æ 0.

4 Schematy danych

Poni¿ej zaprezentowano skrypt tworz±cy obiekty w relacyjnej bazie danych oraz opis struktury danych, w formacie LDIF, przechowywanych w serwerze katalogowym.

4.1 Skrypt tworz±cy schemat danych w bazie relacyjnej (Oracle)

drop sequence pt_lg_seq

drop table pt_users_groups

drop table pt_groups

drop table pt_user_props

drop table pt_users

create sequence pt_lg_seq

start with 1000

increment by 1

order

nocache

prompt table pt_users

create table pt_users(

us_id number(10) not null

,us_po_id varchar2(80) not null

,us_login varchar2(30) not null

,us_password varchar2(30) not null

,us_enabled varchar2(10) not null

,us_email varchar2(120) not null

,us_mobile varchar2(20)

,us_fname varchar2(60) not null

,us_sname varchar2(120) not null

,us_admin varchar2(10) not null

,us_mod_date date not null

,us_mod_user varchar2(30) null

,us_login_date date

,us_last_login_date date

,constraint us_pk primary key(us_id)

,constraint us_ck1 check(us_enabled in ('YES', 'NO'))

,constraint us_ck2 unique(us_po_id, us_login)

,constraint us_ck3 check(us_admin in ('YES', 'NO'))

)

prompt table pt_user_props

create table pt_user_props(

up_id number(10) not null

,up_us_id number(10) not null

,up_name varchar2(250) not null

,up_value varchar2(4000) not null

,constraint up_pk primary key(up_id)

,constraint up_fk1 foreign key(up_us_id)

references pt_users(us_id)

,constraint up_ck1 unique(up_us_id, up_name)

)

prompt table pt_groups

create table pt_groups(

gr_id number(10) not null

,gr_po_id varchar2(80) not null

,gr_name varchar2(30) not null

,gr_title varchar2(60) not null

,gr_description varchar2(4000) not null

,gr_mod_date date not null

,gr_mod_user varchar2(30) null

,constraint gr_pk primary t-size:9.0pt;mso-bidi-font-size:12.0pt;font-family:"Courier New"; mso-ansi-language:EN-US'> ,constraint gr_ck1 unique(gr_po_id, gr_name)

)

prompt table pt_users_groups

create table pt_users_groups(

ug_us_id number(10) not null

,ug_gr_id number(10) not null

,ug_mod_date date not null

,ug_mod_user varchar2(30) null

,constraint ug_pk primary key(ug_us_id, ug_gr_id)

,constraint ug_fk1 foreign key(ug_us_id)

references pt_users(us_id) on delete cascade

,constraint ug_fk2 foreign key(ug_gr_id)

references pt_groups(gr_id) on delete cascade

)

4.2 Schemat danych w bazie katalogowej (iPlanet Directory Server)

Poni¿ej przedstawiono plik w formacie LDIF. Serwer katalogowy iPlanet Directory Server przechowuje w tym formacie informacje o strukturze sk³adowanych danych.

# psncPortal Schema

dn: cn=schema

# "psncPortal" attributes

attributeTypes: ( psncGroupId-oid

NAME 'psncGroupId'

DESC 'PSNC Portal Group Id'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27

SINGLE-VALUE X-ORIGIN 'user defined')

attributeTypes: ( psncGroupTitle-oid

NAME 'psncGroupTitle'

DESC 'PSNC Portal Group Title'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

SINGLE-VALUE X-ORIGIN 'user defined' )

attributeTypes: ( psncPropertyId-oid

NAME 'psncPropertyId'

DESC 'PSNC Portal User'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE

X-ORIGIN 'user defined')

attributeTypes: ( psncPropertyValue-oid

NAME 'psncPropertyValue'

DESC 'PSNC Portal User Property'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE

X-ORIGIN 'user defined' )

attributeTypes: ( psncUserId-oid

NAME 'psncUserId'

DESC 'PSNC Portal User Id'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE

X-ORIGIN 'user defined')

attributeTypes: ( psncUserEnabled-oid

NAME 'psncUserEnabled'

DESC 'PSNC Portal User Enable Flag'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.7

SINGLE-VALUE X-ORIGIN 'user defined' )

attributeTypes: ( psncUserAdmin-oid

NAME 'psncUserAdmin'

DESC 'PSNC Portal User Admin Flag'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE

X-ORIGIN 'user defined' )

attributeTypes: ( psncModDate-oid

NAME 'psncModDate'

DESC 'PSNC Portal Modification Date'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

SINGLE-VALUE X-ORIGIN 'user defined')

attributeTypes: ( psncModUser-oid

NAME 'psncModUser'

DESC 'PSNC Portal Modification User'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE

X-ORIGIN 'user defined')

attributeTypes: ( psncLastLoginDate-oid

NAME 'psncLastLoginDate'

DESC 'PSNC Portal User'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE

X-ORIGIN 'user defined' )

attributeTypes: ( psncLoginDate-oid

NAME 'psncLoginDate'

DESC 'PSNC Portal User'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE

X-ORIGIN 'user defined')

# Object class definitions

objectClasses: ( psncportaluser-oid

NAME 'psncportaluser'

SUP top

STRUCTURAL MUST ( givenName $ mail $ mobile $ psncLastLoginDate $ psncLoginDate

$ psncModDate $ psncModUser $ psncUserAdmin $ psncUserEnabled $er:none; mso-border-alt:solid windowtext .5pt;padding:0cm;mso-padding-alt:1.0pt 4.0pt 1.0pt 4.0pt'> $ sn $ uid $ userPassword )

X-ORIGIN 'user defined' )

objectClasses: ( psncportaluserproperty-oid

NAME 'psncportaluserproperty'

SUP top

STRUCTURAL MUST ( cn $ psncPropertyId $ psncPropertyValue)

X-ORIGIN 'user defined' )

objectClasses: ( psncportalgroup-oid

NAME 'psncportalgroup'

SUP top

STRUCTURAL MUST ( cn $ description $ psncGroupId $ psncGroupTitle $ psncModDate

$ psncModUser )

X-ORIGIN 'user defined' )

objectClasses: ( psncportaluseringroup-oid

NAME 'psncportaluseringroup'

SUP top

STRUCTURAL MUST ( psncModDate $ psncModUser $ psncUserId $ seeAlso $ uid )

X-ORIGIN 'user defined' )

5 Konfiguracja i uruchomienie

5.1 Konfiguracja aplikacji

Aplikacjê do kopiowania danych u¿ytkowników portalu nale¿y skonfigurowaæ definiuj±c nastêpuj±ce pliki konfiguracyjne.

dbLdap.properties

portalId=[identyfikator portalu]

dataSource=ikdev #nazwa bazy ¼ród³owej

dataSource.type=[db|ldap] #typ bazy ¼ród³owej

dataTarget=ldaptest #nazwa bazy docelowej

dataTarget.type=[db|ldap] #typ bazy docelowej

#definicja parametrów konfiguracyjnych relacyjnej bazy danych

#ikdev - oznaczenie bazy, zdefiniowane powy¿ej

ikdev.db.connectString=jdbc:oracle:thin:@[host]:1521:[nazwa bazy danych]

ikdev.db.user=[nazwa konta bazy danych]

ikdev.db.password=[has³o do bazy danych]

ikdev.db.driverClassName=oracle.jdbc.driver.OracleDriver

ikdev.db.maxConnections=10

#definicja parametrów konfiguracyjnych katalogowej bazy danych

# ldaptest - oznaczenie bazy, zdefiniowane powy¿ej

ldaptest.ldap.minPoolSize=5

ldaptest.ldap.maxPoolSize=10

ldaptest.ldap.Host=[host]

ldaptest.ldap.Port=[port]

ldaptest.ldap.AuthDN=[DN u¿ytkownika bazy katalogowej]

ldaptest.ldap.AuthPW=[has³o u¿ytkownika bazy katalogowej]

ldaptest.ldap.RootDN=[korzeñ drzewa w katalogu]

#UWAGA: Interfejs s³u¿±cy do sk³adowania danych w bazie katalogowej wykorzystuje

#mechanizmy relacyjnej bazy danych do generowania unikalnych identyfikatorów u¿ytkowników.

#Dostêp do bazy relacyjnej nale¿y zdefiniowaæ nastêpuj±co:

ldaptest.db.connectString=jdbc:oracle:thin:@[host]:1521:[nazwa bazy danych]

ldaptest.db.user=[nazwa konta bazy danych]

ldaptest.db.password=[has³o do bazy danych]

ldaptest.db.driverClassName=oracle.jdbc.driver.OracleDriver

ldaptest.db.maxConnections=10

log4j.props

# global

log4j.rootCategory=ALL, LC, LF

# ograniczenia

log4j.category.man7=ERROR, LC

log4j.category.PoolManStat=ERROR, LC

log4j.category.pl.psnc.portal.sql=ERROR, LC

#log4j.category.pl.psnc.portal.cache=DEBUG, LC

# console

log4j.appender.LC=org.apache.log4j.ConsoleAppender

log4j.appender.LC.layout=org.apache.log4j.PatternLayout

log4j.appender.LC.Threshold=ALL

log4j.appender.LC.layout.ConversionPattern=%d %-11t %-5p %-25c %m%n

# global file

log4j.appender.LF=org.apache.log4j.RollingFileAppender

log4j.appender.LF.File=[¶cie¿ka do pliku logu]

log4j.appender.LF.MaxFileSize=1MB

log4j.appender.LF.MaxBackupIndex=9

log4j.appender.LF.layout=org.apache.log4j.PatternLayout

log4j.appender.LF.layout.ConversionPattern=%d %-11t %-5p %-25c %m%n

5.2 Uruchomienie aplikacji

Do poprawnego dzia³ania aplikacja wymaga wirtualnej maszyny Javy w wersji 1.4 oraz dostêpno¶ci nastêpuj±cych bibliotek:

log4j-1.2.8.jar - pakiet log4j

joshua40-core.jar - pakiet portalowy Joshua

freemarker.jar - pakiet obs³ugi szablonów Freemarker

poolman.jar - pakiet z implementacj± puli po³±czeñ do bazy danych

classes12.jar - pakiet sterowników JDBC firmy Oracle

ocrs12.jar - pakiet sterowników JDBC firmy Oracle

dbldap.jar - pakiet aplikacji

ldapfilt41.jar - pakiet sterowników dla dostêpu do bazy katalogowej LDAP

ldapjdk41.jar - pakiet sterowników dla dostêpu do bazy katalogowej LDAP

ldapsp41.jar - pakiet sterowników dla dostêpu do bazy katalogowej LDAP

Uruchomienie aplikacji nale¿y poprzedziæ utworzeniem konta docelowej bazy danych, utworzeniem docelowego schematu danych i zdefiniowaniem plików konfiguracyjnych. Uruchomienie aplikacji realizowane jest z linii poleceñ.

Aplikacja przyjmuje nastêpuj±ce parametry uruchomieniowe:

DbLdapCopy [-mix] [-props s] [-probe i] [-package i] [-mcprob d]

[-fcprob d] [-lcprob d] [-ecprob d] [-pcprob d] [-prprob d]

gdzie:

-mix -> kopiuj z anonimizacj± danych

-props s -> ¶cie¿ka do pliku z w³asno¶ciami

-probe i -> liczba rekordów do skopiowania (je¶li nie ca³a baza)

-package i -> wielko¶æ pakietu jednorazowo kopiowanego/anonimizowanego

-mcprob d -> prawdopodobieñstwo jednorazowej zmiany numeru telefonu komórkowego

-fcprob d -> prawdopodobieñstwo jednorazowej zmiany imienia

-lcprob d -> prawdopodobieñstwo jednorazowej zmiany nazwiska

-ecprob d -> prawdopodobieñstwo jednorazowej zmiany adresu e-mail

-pcprob d -> prawdopodobieñstwo jednorazowej zmiany w³asno¶ci

-prprob d -> prawdopodobieñstwo jednorazowego przeniesienia w³asno¶ci

s - ³añcuch znaków

i - liczba ca³kowita

d - liczba zmiennoprzecinkowa [0-1]

Przyk³adowe uruchomienie, w którego wyniku nast±pi skopiowanie 200 rekordów opisuj±cych u¿ytkowników wraz z anonimizacj± ich danych osobowych.

java -Dlog4j.configuration=file:log4j.props -classpath \

.\lib\dbldap.jar; \

.\lib\ldapfilt41.jar; \

.\lib\ldapjdk41.jar; \

.\lib\ldapsp41.jar; \

.\lib\log4j-1.2.8.jar; \

.\lib\joshua40-core.jar; \

.\lib\classes12.jar; \

.\lib\nls_charset12.jar; \

.\lib\ocrs12.jar; \

.\lib\poolman.jar; \

.\lib\freemarker.jar \

pl.psnc.dbldap.DbLdapCopy -props .\DbLdapCopy.properties -mix -probe 200

6 Podsumowanie

Zaprezentowana aplikacja pozwala na kopiowanie danych u¿ytkowników portalu dzia³aj±cego w oparciu o pakiet portalowy Joshua. Aplikacja zosta³a zaimplementowana w jêzyku Java i wykorzystuje mechanizmy dostarczane przez zunifikowany interfejs zarz±dzania u¿ytkownikami pakietu portalowego Joshua.

Aplikacja konfigurowana jest za pomoc± pliku konfiguracyjnego, w którym okre¶lane s± parametry ¼ród³owej oraz docelowej bazy danych (relacyjnej lub LDAP), co pozwala w ³atwy sposób dokonywaæ kopiowania danych. Przed uruchomieniem aplikacji konieczne jest przygotowanie docelowej bazy danych i utworzenie w niej w³a¶ciwego schematu danych. Wykonywane operacje kopiowania danych s± logowane do pliku z wykorzystaniem pakietu log4j.

Wykorzystanie aplikacji pozwoli wykonywaæ kopie baz danych u¿ytkowników portali dzia³aj±cych w oparciu o pakiet portalowy Joshua w celu ewentualnej migracji danych i tworzenia ¶rodowisk testowych rozwijanych portali.

7 Bibliografia

[ 1 ]	T.A. Howes, M.C. Smith, G.S. Good "Understanding and Deploying LDAP Directory Services", 1999
[ 2 ]	Netscape Directory SDK for Java http://developer.netscape.com/tech/directory/index.html
[ 3 ]	Ustawa z dnia 29 sierpnia 1997 o Ochronie danych osobowych (Dz.U. 1997 Nr 133 poz. 883) http://isip.sejm.gov.pl/PRAWO.nsf/Main/WDU19971330883?OpenDocument
[ 4 ]	Opis portalu dzia³aj±cego w oparciu o pakiet portalowy Joshua http://www.man.poznan.pl/badania/interklasa/index.html