Category: Administracja

OE Management

OpenEdge Management (OEM), następca Fathom Management, jest dobrze znany administratorom baz danych od wielu lat. Jego zubożona wersja, OpenEdge Explorer, jest dołączana darmowo do licencji serwera baz danych. Jest więc narzędziem bardzo popularnym i ze względu na interfejs webowy, stosowanym na każdej platformie. Postanowiłem więc cofnąć się do tego produktu i napisać o kilku kwestiach, co do których pojawiają się pytania i niejasności.

O OE Explorer pisałem już tutaj.

Przypomnijmy za dokumentacją OpenEdge przykładowe konfiguracje w jakich może pracować OEM. Pierwsza, gdy wszystkie komponenty OEM znajdują się na jednej maszynie przedstawia poniższy rysunek.

Z punktu widzenia monitorowania mamy dwa rodzaje baz: baza zarządzana (managed database), taka która rejestruje się i jest zarządzana przez AdminServer oraz baza skryptowa (scripted database) jest to baza nie zarządzana przez AdminServer – w tym  przypadku trzeba na maszynie zdalnej trzeba wystartować proces dbagent. Aby to zrobić na maszynie host dodajemy w zasobach zdalnych bazę skryptową. Następnie odczytujemy komendę jaką należy uruchomić na maszynie remote np.

dbagent -db C:\WrkOpenEdge123\db\sports2000 -H hostname -S 8850 -ipver IPv4 (-S jest portem nasłuchu OEM, nie bazy).
Po uruchomieniu tej komendy agent kontaktuje się z OEM na maszynie host. Każdą bazę scripted można w prosty sposób zamienić w konsoli OEM na managed, Musi być ona uruchomiona z parametrem -S.

Poniższa konfiguracja jest już bardziej złożona – na trzech maszynach A, B i C jest zainstalowany AdminServer. Monitorowanie odbywa się na maszynie A (host). Maszyny B i C (remote) przesyłają dane do hosta. O tym jak wygląda ta komunikacja, napiszę za chwilę. Na maszynach B i C można mieć zainstalowany także OEM i skonfigurowane wszystkie potrzebne lokalne zasoby. W tej sytuacji poprzez zdalne AdminServery mamy dostęp do wszystkich trzech środowisk i to wszystko z jednej konsoli OEM.


Teraz w OEM na hoście możemy dodać zdalne AdminServery i monitorować te maszyny z jednej konsoli. Przykład mamy na poniższym rysunku.

Tu dochodzimy do ważnego punktu. Otóż w wersji OE 11.3 zmienił się mechanizm zdalnego monitorowania (messaging system), SonicMQ został zastąpiony przez ActiveMQ.
Jeśli monitorujemy środowisko posiadając wersję OE 11.3 lub wyższą możemy monitorować bazy scripted w niższych wersjach niż 11.3. Dzieje się tak dlatego, że dbagent nie korzysta z AdminServera.
Jednakże w sytuacji gdy monitorujemy całe kontenery, czyli zdalne AdminsServery, to musimy zachować kompatybilność z systemem przesyłania komunikatów. Czyli, posiadając wersję 11.3+ możemy monitorować inne wersje OE 11.3+. Jeśli zachodzi potrzeba monitorowania wcześniejszych wersji OE, trzeba zainstalować wcześniejsza wersję OEM z systemem SonicMQ.
Korzyść płynąca z ActiveMQ to większa niezawodność, ponadto możemy mieć na wszystkich maszynach zainstalowany nie tylko AdminServer ale także OEM, który w kapitalnym stopniu ułatwia konfigurację. W poprzednich wersjach po przeprowadzeniu konfiguracji trzeba było “wyłączyć” produkt OEM poprzez instrukcję unglue (włączenie instrukcją glue). W ActiveMQ nie mam tej potrzeby. W OE 12 nie ma nawet takiej instrukcji.

Administracja , , , ,

Bezpieczeństwo w PASOE cz. V – OE Realm

Po ostatnim artykule dostałem pytanie: czy można wykorzystać obiekt CLIENT-PRINCIPAL w PASOE bez konieczności korzystanie z LDAP. Otóż można i zaraz pokażę jak to zrobić na podstawie informacji zaczerpniętych z bazy wiedzy (000194706). (Uwaga: technika ta dotyczy wersji OE 12.2. W bazie można znaleźć podobne rozwiązanie np. dla OE 11, które nie działa poprawnie).

Na początek trzeba powiedzieć czym jest OERealm. Jest to implementacja SPA (Single Point of Authentication), rozszerzająca proces uwierzytelniania Spring Security. Implementacja ta składa się z komponentu klienta i servera OERealm napisanych w języku obiektowym ABL (OO ABL).


Źródłem danych może być nie tylko baza, ale także omawiane wcześniej LDAP lub inne żródło.
OE Realm Service Interface jest klasą OO ABL, która zawiera metody sprawdzające tożsamość użytkownika i dostarczające informację o atrybutach zweryfikowanego użytkownika.

Po stronie klienta należy zaimplementować własny proces uwierzytelniający. Aktualnie klientem OE Realm może być REST, BPM i Rollbase.

W niniejszym artykule zajmiemy się uwierzytelnianie klientów REST, przy czym dane użytkowników są zdefiniowane w tabeli _User w domenach bazy danych OpenEdge.

Na początek przygotujmy bazę (realmdb, kopia bazy sports2000), dadajmy domenę RealmDom, kod dostępu do domeny realmpa.

Dodajmy użytkownika restuser1 do domeny RealmDom oraz user1 do domeny pustej (hasło np. takie samo jak nazwa użytkownika).

Teraz trzeba stworzyć rolę i nadać ją użytkownikowi restuser1…


CREATE _Sec-role.
ASSIGN _Role-name = “PSCUser”
_Role-description = “User level role”.
_Role-creator = “”. /* Name of the user or Role that created this role */

CREATE _sec-granted-role.
ASSIGN _sec-granted-role._grantee = “restuser1@RealmDom”.
_sec-granted-role._role-name = “PSCUser”.
_sec-granted-role._grantor = “”. /* the user or role that granted use of this role */
_sec-granted-role._grant-rights = YES.
_sec-granted-role._granted-role-guid = substring(base64-encode(generate-uuid), 1, 22).

…oraz sekwencję wymaganą przez klasę OEUserRealm.cls.


USING OpenEdge.DataAdmin.*.

DEFINE VARIABLE sequence AS ISequence NO-UNDO.
DEFINE VARIABLE service AS CLASS DataAdminService.
service = NEW DataAdminService().

sequence = service:NewSequence("Next-User-Num").

sequence:InitialValue = 1.
sequence:IncrementValue = 1.
sequence:IsCyclic = FALSE.
sequence:MaximumValue = ?.

service:CreateSequence(sequence).

Tworzymy nową instancję PASOE (nazwałem ją realmpas) z przyłączoną bazą realmdb.
Aby tylko ta instancja mogła uruchomić plik klasy Oe Realm, wygenerujemy plik CP poleceniem:
genspacp -user oerealm -password RESTSPAPassword -role RESTSpaClient -file realm.cp

W komendzie tej dane użytkownika nie mają nic wspólnego z użytkownikami zdefiniowanymi w bazie.
Dane te będą znajdować się w pliku spaservice.properties, który należy umieścić w podkatalogu …/realmpas/openedge.
Wygenerowany plik realm.cp umieścimy natomiast w podkatalogu …/realmpas/common/lib/.

Teraz, podobnie jak w poprzednim artykule, wygenerujemy zaszyfrowany plik rejestru. Najpierw tworzymy prosty plik tekstowy domreg.csv zawierający tylko jedną linię: nazwa domeny, kod dostępu.
RealmDom, realmpa.
Zaszyfrowany plik generujemy poleceniem gendomreg domreg.csv ABLDomainRegistry.keystore.
Nazwa pliku jest dowolna. W tym przykładzie jest to nazwa domyślna, używana w pliku z ustawieniami PASOE. Umieszczamy go w podkatalogu …/realmpas/conf.
Plik OEUserRealm.properties kopiujemy do podkatalogu …/realmpas/openedge. Zawiera on tylko dwie linie:

validateCP=true
debugMsg=true

Wszystkie pliki potrzebne aby uruchomić ten przykład możemy pobrać STĄD.

Przejdżmy teraz do Developer’s Studio i stwórzmy prosty projekt oparty na naszym PASOE typu REST z wykorzystaniem JSDO (pokazywałem kiedyś jak to zrobić na tym blogu). W projekcie tym (nazwałem go myrealm) tworzymy Busineee Entity dla tabeli Customer. Zresztą, może to być jakikolwiek inny projekt dla serwisu REST. Mamy więc projekt i wygenerowany podkatalog AppServer. Importujemy do tego podkatalogu pobraną strukturę psc/stat/realm z plikami klasy.
Jeśli tworzycie takie projekty to pewnie dobrze wiecie jak to zrobić. Jeśli nie, to wg. mnie, najwygodniej utworzyć plik zip tylko ze strukturą i plikami, które chcemy zaimportować (pobrany plik .zip zawiera także ustawienia, plik .cp itp.), a następnie klikamy prawym klawiszem na podkatalog AppServer i wybieramy import -> Archive File. Radzę skasować pliki .r ponieważ były skompilowane dla bazy sports2000 i mogą generowac błędy.

Przechodzimy teraz do pliku z ustawieniami PASOE oeablSecurity.properties. Możemy to zrobić bezpośrednio w podkatalogu …\realmpas\webapps\myrealm\WEB-INF, bądź z Dev. Studio pod naszym projektem PASOEContent/WEB-INF/oeablSecurity.properties.

Dodajemy w nim ustawienia lub upewniamy się, że są tam takie jak poniżej (niektóre ustawienia powinny mieć domyślne wartości).

http.all.authmanager=oerealm
client.login.model=form

OEClientPrincipalFilter.enabled=true
OEClientPrincipalFilter.registryFile=ABLDomainRegistry.keystore

OERealm.UserDetails.realmClass=psc.stat.realm.OEUserRealm
OERealm.UserDetails.grantedAuthorities=ROLE_PSCUser.ROLE_PSCAdmin,ROLE_PSCDebug
OERealm.UserDetails.appendRealmError=false
OERealm.UserDetails.realmTokenFile=realm.cp

W ustawieniach PASOE dodajemy procedurę activate.p. Można to zrobić w OE Explorer (jak poniżej), w pliku openedge.properties lub w Dev. Studio Open Launch configuration -> Startup. Ta ostatnia metoda ustawia zmienne tylko tymczasowo i jest bardzo wygodna w testowaniu.
Procedura ta jest zapisana w podkatalogu …/realmpas/openedge. Uruchamia ona procedurę dumpCP.p, którą także musimy umieścić w tym katalogu. Zapisuje ona do logu dane o Client-Proncipal.

Po tych wszystkich zabiegach tak wygląda podkatalog …/realmpas/openedge…

… a tak pliki w projekcie.

Uruchamiam PASOE i próbuję zalogować się do mojego serwisu: http://localhost:8853/myrealm/static/auth/login.jsp

Próba jest udana i w logu agenta możemy znaleźć nast. informacje:

.....
(Procedure: 'dumpCP.p' Line:16) psc.stat.realm.OEUserRealm&ValidateUser Client-Principal:
(Procedure: 'dumpCP.p' Line:17) ID:         'oerealm@OESPA'
(Procedure: 'dumpCP.p' Line:18) session-id: 1ehUo504Taq+XFpP8CFSMw
(Procedure: 'dumpCP.p' Line:19) state:      SSO
(Procedure: 'dumpCP.p' Line:25) details: The CLIENT-PRINCIPAL object credentials were validated by an external system
(Procedure: 'dumpCP.p' Line:27) roles: RESTSpaClient
.....
(Procedure: 'ValidateUser psc.stat.realm.OEUserRealm' Line:590) Lookup ABL user account for: restuser1@RealmDom
(Procedure: 'ValidateUser psc.stat.realm.OEUserRealm' Line:599) ValidateUser found user: restuser1@RealmDom
(Procedure: 'ValidateUser psc.stat.realm.OEUserRealm' Line:613) Lookup user account for: restuser1@RealmDom returned id: 2
.....

Pliki klas możemy oczywiście napisać sami, ale potrzebna jest do tego odpowiednia wiedza. Na początek warto bazować na tych przykładowych plikach.
I to by było na tyle.

Administracja , , ,

Bezpieczeństwo w PASOE cz. IV – LDAP, domeny i CP

W poprzednim artykule wyszliśmy poza technologię Progress Software i dzięki Apache Directory Studio przeprowadziliśmy uwierzytelnienie użytkowników korzystających z restowej aplikacji PASOE.

Pora wykonać następny krok (naprzód!) i uwzględnić w całym procesie token – obiekt CLIENT-PRINCIPAL. Obiekt ten został wprowadzony w OE10, wraz z pojawieniem się technologii Auditing. Przypomnę, że chodziło o rejestrowanie zmian w systemie bazodanowym i niezbędnym było posiadanie informacji, kto te zmiany wprowadza. Domyślnie, auditing korzysta z wartości user-id użytkownika, który jest zdefiniowany w bazie.

Jednakże w kontekście aplikacji bardziej odpowiedni jest identyfikator użytkownika sesji OpenEdge. Dzięki takiemu identyfikatorowi – tokenowi, aplikacja nie musi sprawdzać za każdym razem gdy jest to konieczne, kto jest aktualnie zalogowany. Wszystkie potrzebne informacje są bezpiecznie przechowywane w obiekcie sesji CLIENT-PRINCIPAL. Obiekt ten może zawierać nie tylko dane użytkownika, ale dodatkowe właściwości jak np. role potrzebne w procesie autoryzacji.

CLIENT-PRINCIPAL (CP) jest szczególnie przydatny w aplikacjach rozproszonych (AppServer, PASOE) ponieważ może zarządzać kontrolą dostępu dla wielu procesów aplikacji.

Nie będę omawiał wszystkich szczegółów związanych z CP, gdyż jest to temat zbyt obszerny. Bardzo ważne jest to, że do “zapieczętowania” (seal) obiektu i późniejszego jego użycia w sesji, użytkownik musi być zdefiniowany w tzw. domenie i musi być znany klucz (Access Code) do domeny. Czyli: definiujemy domeny w bazie (nazwa domeny, klucz dostępu), a następnie definiujemy użytkownika w danej domenie. OK, to powinno nam na razie wystarczyć. Na poniższym rysunku widać narzędzie Database Administration i okno do definiowania domen ( opcja: Admin -> Security -> Domain Maintenance -> Domains…).

Teraz uwaga! użytkownicy nie muszą znajdować się w bazie, mogą być zdefiniowani w systemie LDAP, co zaraz pokażę. Definicje domen w bazie będą jednak potrzebne. Później wyjaśnię dlaczego.

Teraz jest dobry moment żeby podłączyć PASOE do serwera bazy danych.

Proszę zwrócić uwagę na dwie domeny: adminusers i webusers (opis: LDAP), które zdefiniowałem na potrzeby tego artykułu. Kodem dostępu do domen jest odpowiednio: adminpa, webpa.
Tworzymy prosty tekstowy plik zawierający pary wartości: nazwa domeny, kod dostępu. Zobaczmy taki przykładowy plik ldapasreg.csv.

Posłuży on jako parametr wejściowy do utworzenia zaszyfrowanego pliku rejestru, który może służyć do zapieczętowania tokena. W oknie znakowym podajemy komendę:
gendomreg ldapasreg.csv ldapasreg.bin.
Wygenerowany plik ldapasreg.bin kopiujemy do podkatalogu PASOE conf.

Teraz zabieramy się za modyfikację struktury w Apache Directory Studio. Po uruchomieniu instancji serwera i otwarciu połączenia dodajemy dwie grupy: OED:adminusers, OED:webusers. Jak łatwo się domyślić, to są nasze domeny. W LDAP nie ma obiektów typu domena, więc definiujemy grupy, a żeby odróżnić je od zwykłych grup dodajmy np. przedrostek. Użyłem przedrostka OED:, ponieważ oznacza OpenEdge Domain, ale można użyć dowolnego jaki nam pasuje.


W grupie OED:adminusers dodałem użytkownika Piotr Adminowy (czyli admin1), a w domenie OED:webusers użytkownika Marek Webowy (user1). Tym samym należą oni do dwóch grup (drugą jest PSCUser).

Przechodzimy do pliku: [working directory]\[instancja pasoe]\webapps\ROOT\WEB-INF\oeablSecurity.properties i dodajemy ustawienia:

## OEClientPrincipalFilter.registryFile=ABLDomainRegistry.keystore
OEClientPrincipalFilter.registryFile=ldapasreg.bin
...
 ## Used to obtain an OE Domain name from the authenticated user's list of
 ## roles if the user did not supply one (overrides the default domain property)
 OEClientPrincipalFilter.domainRoleFilter=ROLE_OED:(.*)

Pierwszy parametr określa binarny plik, który utworzyliśmy wcześniej, drugi to prefix określający domenę. Z poprzedniego artykułu wiemy, że dla określenie roli, do nazwy grupy użytkownika zostanie dodany prefix ROLE_ (parametr ldap.authpopulator.rolePrefix). Natomiast dla określenia domeny, zostanie zidentyfikowany ciąg znaków ROLE_OED: i wszystko co nastąpi po nim, to nazwa domeny. Czyli dla użytkownika admin1 będzie to adminusers, a dla user1 webusers.
Ponieważ w pliku binarnym istnieje taka domena i kod dostępu, uwierzytelnienie powinno się udać.

Zanim przejdę dalej trzeba odpowiedzieć na jedno ważne pytanie: dlaczego informacje o domenach znajdują się w trzech miejscach: bazie danych, pliku bin, serwerze LDAP? Aby to zrozumieć musimy przypomniec sobie, że PASOE to połączenie dwóch technologii: ABL i Java (Tomcat). W Spring Security (Java) tworzony jest token, który Tomcat może zapieczętować dzięki informacjom w pliku bin. Token ten jest transformowany do CLIENT-PRINCIPAL ABL, dzięki czemu możemy korzystać z metod ABL aby np. modyfikować role, zarządzać stanem CP itd. CP nie korzysta z pliku bin, dane o domenach pobiera z bazy. Tutaj w bazie nie trzeba definiować użytkowników w domenach, są oni zdefiniowani tylko na serwerze LDAP.

Ponieważ możemy teraz korzystać z obiektu CP, dodajmy dwie procedury w konfiguracji naszej instancji PASOE, dla otwarcia sesji i rozpoczęciu żądania. Całe procedury można pobrać tutaj.


Pierwsza procedura wczytuje parametry domen z bazy.
cpStartup.p

// Loading domain registry for the session
m_lOK = SECURITY-POLICY:LOAD-DOMAINS(1).

pcActivate.p weryfikuje poprawność zapieczętowania CP i wydruk jego atrybutów do logu.
cpActivate.p

// Verify if the Client-Principal is sealed successfully or not. If not, return error.
IF lOK THEN 
DO:
    // Dump the Client-Principal attributes
   
    MESSAGE "    ID:         '" + hCP:QUALIFIED-USER-ID + "'".
    MESSAGE "    session-id:" hCP:SESSION-ID.
    MESSAGE "    state:" hCP:LOGIN-STATE.
    MESSAGE "    roles: " + hCP:ROLES.
    MESSAGE "     domain: " + hCP:DOMAIN-NAME.
    
    cList = hCP:LIST-PROPERTY-NAMES.
    iListSize = NUM-ENTRIES(cList, ",").
    IF ( 0 < iListSize ) THEN 
    DO iListPos = 1 TO iListSize:
        DEFINE VARIABLE cProp AS CHARACTER NO-UNDO.
        DEFINE VARIABLE cVal  AS CHARACTER NO-UNDO.

        MESSAGE "    properties:".
        cProp = ENTRY(iListPos, cList, ",").
        cVal = hCP:GET-PROPERTY(cProp).
        MESSAGE "          property:" cProp ", value:" cVal.
    END.
    
    // Set the Client-Principal as client to connect with DB.
    SET-DB-CLIENT(hCP).
    
END.

Restartujemy teraz PASOE i wywołujemy ekran logowania: http://localhost:[port]/rest/_oepingService/_oeping
Podajemy dane: user1, user1. Dane są uwierzytelnione, ale najciekawsze informacje znajdujemy w logu agenta ldapas.agent.[data].log
Po pierwsze mamy wpis o prawidłowym wczytaniu domen z pliku cpStartup.p

Po drugie możemy odczytać parametry tokena CLIENT-PRINCIPAL wygenerowane przez plik cpActivate.p.

Widać, że pełne id użytkownika zostało uzupełnione o nazwę domeny a także, że użytkownik dostał nową rolę.
To chyba jest najbardziej zaawansowany z artykułów, które do tej pory Wam przedstawiłem. Jeśli ktoś przećwiczy cały proces – gratuluję!
W razie pytań piszcie, jak zwykle, na PUG Poland.

Administracja , , ,

Bezpieczeństwo w PASOE cz. III – LDAP

W tym artykule powracamy do tematu związanego z bezpieczeństwem w PASOE, które było omawiane ok. pół roku temu. Dla przypomnienia: część I oraz część II. Warto przypomnieć sobie te wiadomości bo będziemy z nich zaraz korzystać.

Spring Security to elastyczny framework, w którym administrator może wybrać poziom  zabezpieczeń w zależności od wymagań związanych z aplikacją. Pokażę jak przeprowadzić uwierzytelnienie użytkowników, którzy nie znajdują się w bazie, nie są zdefiniowani w plikach tekstowych, ale w zewnętrznym systemie LDAP, na przykładzie Apache Directory.

Instalujemy Apache Directory Studio, które zawiera serwer LDAP oraz środowisko oparte na Eclipse, do stworzenia hierarchicznej struktury, zawierającej m.in. konta użytkowników.

Na temat tworzenia takiej struktury w ADS czy innym systemie LDAP (Active Directory, OpenLDAP, itp) można znaleźć wiele informacji w sieci. Bardzo przydatne na początku są filmiki instruktażowe na youtube. Ja omówię ten proces bardzo ogólnie, na potrzebę niniejszego artykułu. Po pierwsze dodajemy nowy serwer, nazwę go localhost.


W widoku Connections definiuję połączenie dla tego serwera o nazwie local: Hostname: localhost (lub IP), domyślny port 10389.

Następnie w zakładce Authentication, wybieram Bind DN or user: uid=admin,ou=system. Domyślne hasło: secret.

Uruchamiamy zdefiniowany serwer oraz połączenie i możemy przystąpić do tworzenia schematu. Trzeba pamiętać, że będzie on dostępny tylko przy aktywnym połączeniu.
Ten schemat można utworzyć na różne sposoby. Ja zacznę od stworzenia obiektu organizacji.
Pod głównym węzłem dc=example,dc=com dodajemy obiekt typu organization o nazwie o=progress
Pod tym elementem tworzymy dwa obiekty typu organizationalUnit ou=groups oraz ou=users.

Pod users dodajemy przykładowych użytkowników typu inetOrgPerson. Dodałem dwóch użytkowników – nasuwa się pytanie jak ich identyfikować, mamy pola cn i sn… – otóż dla identyfikacji z zewnątrz ważny jest atrybut uid (admin1 i user1) oraz userPassword, taki sam jak nazwa użytkownika. Czyli logując się jako zwykły użytkownik (Marek Webowy) podamy dane: user1, user1.

Po uwierzytelnieniu przychodzi pora na autoryzację. Ta jest realizowana za pomocą ról. Zaglądając do poprzednich artykułów możemy zobaczyć, że w pliku pasoe oeablSecurity.csv są zdefiniowane role ROLE_PSCUser, ROLE_PSCAdmin, ROLE_PSCDebug. Dla demonstracji wykorzystamy tylko jedna rolę i stworzymy jedną grupę PSCUser typu groupOfUniqueNames.

W grupie tej umieszczamy użytkowników, tzn. ich atrybuty cn (Common Name). Pamiętajmy, że pełna nazwa zawiera elementy aż do węzła głównego, czyli np. dla użytkownika user1:
cn=Marek Webowy,ou=users,o=progress,dc=example,dc=com.

OK, zrestartujmy połączenie. Możemy teraz przystąpić do konfiguracji PASOE. Ja tworzę nową instancję o nazwie ldapas bez dostępu do bazy.
Konfigurację tę przeprowadzimy w, omawianym już w poprzednich częściach, pliku [working directory]\[instancja pasoe]\webapps\ROOT\WEB-INF\oeablSecurity.properties.
Wybieramy proces zarządzający uwierzytelnieniem ldap oraz model logowania form.

http.all.authmanager=ldap
client.login.model=form

Następnie dodajemy parametry logowania do serwera ldap oraz filtry wyszukiwania informacji o użytkowniku oraz grupie, do której należy.

ldap.root.dn to definicja węzła, od którego zaczyna się wyszukiwanie informacji w strukturze, ldap.usersearch.base to z kolei węzeł, pod którym znajdują się definicje użytkowników, ldap.usersearch.filter określa zakończenie wyszukiwania po znalezieniu elementu uid.

Podobne parametry definiujemy dla grup. Całość wygląda mniej więcej tak:

 ## Required LDAP Server Authentication Manager configuration properties 
 ldap.url=ldap://localhost:10389
 ldap.manager-dn=uid=admin,ou=system
 ldap.manager-password=secret
 
 ldap.root.dn=o=progress,dc=example,dc=com

 ldap.usersearch.base=ou=users  
 ldap.usersearch.searchSubtree=true
 ldap.usersearch.filter=(uid={0})
 
 ldap.grouprole.attribute=cn
 ldap.groupsearch.base=ou=groups
 ldap.groupsearch.searchSubtree=true
 ldap.groupsearch.filter=(uniqueMember={0})

 ldap.authpopulator.rolePrefix=ROLE_

Podawanie hasła w postaci jawnej (secret), to niezbyt dobry pomysł. Można to wyeliminować kodując hasło przy pomocy komendy: stspwdutil encrypt [hasło].

Ostatni parametr (wartość domyślna ROLE_) określa prefix dla roli jaki będzie dodany do nazwy grupy, czyli dla PSCUser pełna nazwa będzie ROLE_PSCUser.

Według konwencji nazewnictwa w LDAP, nazwy ról mają być pisane dużymi literami. W LDAP są one zamieniane z automatu, my musimy zmienić je w pliku oeablSecurity.csv, np. z ROLE_PSCUser na ROLE_PSCUSER itd.

Restartujemy PASOE. Wchodzimy do linku testującego:
http://localhost:[port]/rest/_oepingService/_oeping
Podajemy dane: user1, user1.

Mamy dostęp do serwisu.

OK, ale zazwyczaj nie ma tak dobrze. Często zanim wszystko skonfigurujemy pojawia się komunikat o braku dostępu. W logach nic nie ma, gdzie szukać informacji? Musimy odblokować ilość informacji zapisywanych do logów. W pliku [working directory]\[instancja pasoe]\conf\logging-pasoe.properties zmieniamy poziom zapisów z WARN na DEBUG, a ERROR na INFO, jak poniżej. Konfigurację zapisów do logów możemy zrobić także z poziomu danej aplikacji, ale tutaj poniższa zmiana wystarczy. Uwaga! ta zmiana powoduje znaczne zwiększenie tekstu w logach.

W pliku ldapas_authn.[data].log (przypominam, że moja instancja nazywa się ldapas) znajduje się informacja o udanym uwierzytelnieniu. Informacje o nieudanych logowaniach znajdują się w pliku ldapas_authz.[data].log

[data i czas] ldapas ROOT:f:0000000a success user1

W logu ldapas.[data].log znajduja się m.in. wpisy:

...LdapAuthenticationProvider - Processing authentication request for user: user1...
...FilterBasedLdapUserSearch - Searching for user 'user1', with user search [ searchFilter: '(uid={0})', searchBase: 'ou=users  '...
...Searching for entry under DN 'o=progress,dc=example,dc=com', base = 'ou=users', filter = '(uid={0})'... 
...Found DN: cn=Marek Webowy,ou=users...
......
...Searching for roles for user 'user1', DN = 'cn=Marek Webowy,ou=users,o=progress,dc=example,dc=com', with filter (uniqueMember={0}) in search base 'ou=groups'...
......
...Granted Authorities: ROLE_PSCUSER;...

Wpisów jest wiele, ale można prześledzić proces wyszukiwania oraz uwierzytelniania i autoryzacji.

Następnym razem chciałbym pokazać jak PASOE korzysta z obiektu CLIENT-PRINCIPAL przy autoryzacji LDAP.

Administracja , ,

MOVEit Automation – podstawy

Dzisiaj chciałbym przedstawić podstawy drugiego produktu Ipswitch – MOVEit® Automation.
MOVEit Automation (poprzednia nazwa MOVEit Central) pozwala w łatwy sposób zautomatyzować złożone przepływy danych (workflows) bez konieczności programowania.
Przepływy złożone są z zadań (tasków), a te z kolei mogą być uruchamiane wg harmonogramu, sterowane zdarzeniami lub na żądanie. Zadania mogą wymieniać pliki między systemami wewnętrznymi i zewnętrznymi, w tym serwerami MOVEit Transfer, przy użyciu wielu protokołów i przetwarzać pliki za pomocą wielu wbudowanych funkcji.

O ile miejsce MFT jest w strefie DMZ, to MA powinien znajdować się w bezpiecznej strefie sieci wewnętrznej (patrz rysunek poniżej).

Poniżej widzimy podobną architekturę, gdzie zamiast MFT jest inny produkt z grupy Ipswitch – WS_FTP Server. Możliwe są inne rozwiązania, serwery innych producentów, pominięcie strefy DMZ i połączenie np. z chmurą (MOVEit Cloud), ale o tym innym razem.

MOVEit Transfer (MFT) łatwo skonfigurować do współpracy z MOVEit Automation. W tym celu w MFT dodajemy użytkownika np. micentral z uprawnieniami admina.
Konto to będzie wykorzystywane do wysyłania dużej liczby pakietów dlatego wyłączamy dla niego notyfikacje. Można ustawić odpowiednie zabezpieczenia jak np. mocne hasło czy brak wygaśnięcia konta.
Logujemy się do MOVEit Automation, widzimy główne menu.

klikamy na HOSTS i Add Host. Z listy kilkunastów typów hostów wybieramy MOVEit Transfer.

Podajemy IP oraz dane logowania użytkownika micentral.

Można wprowadzić ograniczenia Limits i Timeouts itd. oraz przetestować połączenie.
Przejdźmy teraz do jednej z podstawowych czynności, tzn. do definiowania tasków.
W głównym menu wybieramy TASKS i Add Task.

Jak widać są trzy rodzaje tasków. Każdy rodzaj ma inne przeznaczenie. Najczęściej definiuje się taski typu Traditional, które zaspokajają większość potrzeb jakie występują w systemie.
Utwórzmy przykładowy tradycyjny task o nazwie myFirstTask. Pierwszym krokiem jest wybór kroku w definiowaniu (przycisk Step): Source, Process, Destination.

Zaczynam od źródła, czyli Source.

Wybieram dodany wcześniej serwer MFT oraz katalog i wzorzec plików, które będą przetwarzane. Możemy dodać czynności po udanym transferze jak np. skasować pliki, zmienić ich nazwę itp. Jeśli klikniemy w opcji Step na Process, dostaniemy listę skryptów do wyboru. Ja ten krok tutaj pominę.

Wybieram natomiast krok Destination, a w nim podaję adres email, na który pliki mają być wysłane.

OK, następny krok to zdefiniowanie harmonogramu (Schedule).

W kroku Next Action można wybrać Send Email, co jest rodzajem notyfikacji oraz ewentualnie Run Task, czyli uruchomienie innego wcześniej zdefiniowanego tasku. W ten sposób można zdefiniować cały cykl zadań.
OK, mój task ma być uruchamiany tylko we wtorki o określonej godzinie. Musimy go jeszcze włączyć i po pewnym czasie mamy raport z jego działania.

Zadania zaawansowane (Advanced Task) podobnie do zadań tradycyjnych mogą również korzystać z procesów. Mogą ponadto używać elementów warunkowych IF i FOR, aby określić, czy i kiedy inne elementy mają być uruchomione.
Elementy te zapewniają kontrolę przepływu pracy bez konieczności programowania.
Trzecim typem zadań sa zadania synchronizujące (Synchronization Task).

Ich zadaniem jest synchronizacja folderów, dlatego konfiguracja składa się z folderu A, folderu B i strzałki określającej kierunek synchronizacji.

MOVEit Automation, podobnie do MFT gwarantuje dostarczenie danych, szyfrowanie danych w spoczynku i szczegółową kontrolę dostępu. Na tym zakończę to wprowadzenie do systemu MA.
Jeśli ktoś ma pytania to proszę o kontakt na grupie PUG Poland.

Administracja, Info ogólne , ,

OpenEdge 12.3

Powróćmy do tematu związanego z OpenEdge, ponieważ już od pewnego czasu mamy na rynku nową wersję OE 12.3.
Zacznijmy od nowinki dla programistów; dodano nową, bardziej zwięzłą instrukcję definicji zmiennych. Do tej pory ile zmiennych chcieliśmy zdefiniować, tyle musieliśmy wstawić definicji. Obecnie zapis jest krótszy, a w jednej instrukcji można zdefiniować wiele zmiennych. Zmienne zdefiniowane poprzez nową instrukcję są zawsze NO-UNDO.

Następna nowinka związana jest z definicją tablicy (extentu) o nieokreślonym rozmiarze. Rozmiar ten można teraz określić podczas fazy runtime, nawet jeśli tablica ma przypisane wartości początkowe.

W ABLu wprowadzono także operatory przypisania (+=, -=, *=, /=) do wykonywania operacji i przypisywania
wartość, używając skróconej notacji.

Od 12.3 jeśli zachodzi potrzeba aktualizacji aplikacji ABL, przy czym ta aktualizacja jest związana z nowymi elementami schematu, nie trzeba już
restartować maszyny wirtualnej ABL (AVM).

W OpenEdge 12.3 dodano ciekawą opcję komendy PROUTIL: PROUTIL TABLEREORG – umożliwia to reorganizację pofragmentowanych danych w tabeli, podczas gdy sama tabela pozostaje dostępna dla operacji OLTP (przetwarzanie transakcji online). Nowy proces zastępuje długotrwałe operacje zrzutu i ładowania danych oraz odbudowy powiązanych indeksów. Rekordy tabeli muszą znajdować się w tym samym obszarze przechowywania typu II. Operacja ta obsługuje także tabele multi-tenant oraz podzielone na partycje.

Kolejne parametry mogą być modyfikowane online, tym razem dla brokera secondary.
Maximum Clients per Server (-Ma)
Maximum Dynamic Server (-maxport)
Minimum Clients per Server (-Mi)
Minimum Dynamic Server (-minport)
Message Buffer Size (-Mm)
Maximum Servers per Broker (-Mpb)
Pending Connection Time (-PendConnTime)

Zmiany parametrów można dokonać w R&D -> opcja 4. Administrative Functions -> 16. Adjust Startup Parameters.

Jest jeszcze kilka ciekawych zmian związanych z tzw. Continuous Operations, bezpieczeństwem, programowaniem, ale to już musicie poszukać w sieci sami.

Administracja, Development, Info ogólne

MOVEit Transfer – klient

W poprzednim artykule opowiedziałem o głównych cechach systemu MOVEit Transfer zainstalowanego na systemie serwerowym. Teraz napiszę o dostępie do niego z poziomu klienta. Potrzebna jest do tego osobna licencja Ad-Hoc Transfer, dzięki której użytkownik posiadający konto w systemie MFT może zainstalować dodatkowe komponenty i mieć dostęp poprzez przeglądarkę webową lub Microsoft Outlook. Użytkownicy mogą więc wymieniać się wiadomościami, przesyłać pliki, co wygląda podobnie do zwykłego systemu Outlook.

Są jednak istotne różnice.Załączniki są wysyłane jako część pakietu nie do odbiorcy, ale na serwer MFT.Do odbiorców wysłany jest e-mail z powiadomieniem o nowym pakiecie.Odbiorca może kliknąć link w tym powiadomieniu, zalogować się do MFT i odebrać pakiet.

Konfiguracja tzw. Moveit Connectora jest bardzo prosta. Potrzebujemy tylko dane logowania użytkownika systemu MFT i oczywiście adres hosta.

W programie Microsoft Outlook, jeśli chcemy skorzystać z nowej możliwości wysyłania pakietów wybieramy MOVEit Send i otrzymujemy poniższy ekran.

Wiadomość możemy wysłać tradycyjnie lub poprzez Send through MOVEit.
Na dole mamy ustawienia: Message body secured oznacza, że treść wiadomości, podobnie jak załączniki, będzie dostępna dopiero po zalogowaniu do MFT. Ustawienie czasu wygaśnięcia i max. ilość pobrań załączników określa administrator. Parametry te synchronizują się z serwerem.

Odbiorca może odpowiedzieć na wiadomość, ewentualnie dodać własne załączniki, ale tylko jeśli takie działanie jest dozwolone. Administrator systemu MFT ma szerokie pole do działania; może np. określać kto może wysyłać i odbierać pakiety, ustawiać limity na poziomie użytkownika lub pakietu oraz kontrolować terminy ważności i pobierania pakietów.

Bardzo duże pliki i dużą ilość załączników można wysyłać szybko i bezpiecznie, unikając ograniczeń serwera pocztowego.

Poniżej znajduje się przykładowy fragment wiadomości jaką odbiorca otrzymuje do skrzynki email. Jest tylko link do systemu. Może on otrzymać w oddzielnej wiadomości hasło do logowania, ale jest to tylko jedna z możliwości. Hasło może być przekazane także w sposób “manualny”.

Jeśli odbiorca nie jest zdefiniowany w systemie tworzony jest użytkownik tymczasowy TempUser a jego nazwa to adres email.

Jest jeszcze jeden produkt typu kienckiego MOVEit Client – bardzo prosty w obsłudze, dający dostęp do katalogu domyślnego oraz katalogów współdzielonych.
Zobaczmy, że w przykładowym systemie dwóch użytkowników (testuser, user1) ma dostęp do katalogu myshared. Ich uprawnienia różnią się nieco, ale obaj mogą wymieniać się danymi.

Użytkownik user1 umieścił w katalogu dwa pliki, które testuser może teraz pobrać i ew. umieścić swoje.

Ponieważ testuser ma uprawnienie List Users może klikając na ikonkę po prawej stronie podejrzeć kto współdzieli ten folder oraz jakie ma w nim uprawnienia.

Administracja, Info ogólne , ,

MOVEit Transfer – podstawy systemu

Do tej pory wszystkie artykuły były związane z technologią OpenEdge. Najwięcej jest poświęconych oczywiście serwerowi aplikacji PASOE. Pora na małą zmianę.
W pierwszej połowie 2019 r. Progress zakupił firmę Ipswitch, Inc., specjalizującą się w rozwiązaniach związanych z bezpiecznym przesyłaniem danych oraz monitorowaniem i zarządzaniem zasobami sieciowymi.

MOVEit® Transfer (poprzednia nazwa MOVEit® DMZ) to cały system do bezpiecznego przetwarzania, przechowywania i przesyłania pakietów.

Produkty z serii MOVEit zapewniają kompleksowe rozwiązania, do bezpiecznej obsługi wrażliwych informacji takich jak dane finansowe, dokumentacja medyczna, dokumenty prawne czy dane osobowe.

No dobrze, powiecie, ale mamy serwery FTP, pocztę elektroniczną – czy to nie to samo i do tego za darmo?

Zabezpieczenia poczty elektronicznej nie zawsze są zgodne z wymaganiami korporacji, a załączane do emaili pliki mają spore ograniczenia dotyczące rozmiaru.

Serwery FTP to oczywiście popularny sposób bezpiecznego przesyłania dużych plików. Problem jest jednak gdy chcemy przekazywać dane wrażliwe (jak powyżej) przy zastosowaniu wymaganych, określonych zabezpieczeń, mieć gwarancję dostarczenia informacji, a do tego tworzyć raporty dotyczące wybranych transferów.

MOVEit® Transfer (MFT) dostarcza bezpieczne usługi przesyłania danych SFTP/S i HTTPS.
Ponadto, dane w systemie MFT są automatycznie szyfrowane nie tylko podczas transferu lecz także w spoczynku.

Zobaczmy dwie podstawowe konfiguracje MFT. Poprzednia nazwa produktu to, jak wspomniałem MOVEit® DMZ, przy czym DMZ oznacza strefę zdemilitaryzowaną, a więc strefę “ograniczonego zaufania” gdzie ryzyko włamania jest zwiększone. W strefie tej umieszcza są serwery, które świadczą usługi użytkownikom sieci wewnętrznej, którzy muszą kontaktować się z użytkownikami sieci zewnętrznej. Po prawej stronie schematu mamy wewnętrznych użytkowników korporacji, która musi mieć bezpieczny dostęp także do użytkowników zewnętrznych (lewa strona).


Zabezpieczenia te można jeszcze podnieść stosując produkt MOVEit Gateway (rysunek poniżej). Miedzy nim a serwerem MFT konfiguruje się tzw. tunelowanie.

Jeśli chodzi o architekturę to nie koniec możliwości, ale na początek poprzestaniemy na tych dwóch prostych przykładach.

MFT jest produktem serwerowym instalowanym na platformie Windows Server. Oznacza to, że próba zainstalowania na maszynie klienckiej zakończy się niepowodzeniem.
Produkt ma dość prosty interfejs webowy, ale bardzo dużo możliwości definiowania poszczególnych elementów w całym systemie przesyłania informacji.

Każdy kto ma dostęp do systemu ma określone uprawnienia oparte na rolach (role-based). Może to być np. administrator, administrator plików, administrator grupy, zwykły użytkownik, użytkownik tymczasowy.

Użytkowników możemy utworzyć od zera lub załadować z istniejącego systemu typu LDAP, SSO itp.

Użytkownicy mogą należeć do grup. Pliki mogą być współdzielone między poszczególnymi użytkownikami lub ich grupami.

Uprawnienia każdego użytkownika można dokładnie zdefiniować pod kątem zabezpieczeń, ograniczeń itd.
Na poniższym rysunku widać sekcję uprawnień związaną z uwierzytelnieniem. Może ono być realizowane przez MOVEit, system zewnętrzny lub oba. Można zdefiniować zasady związane z hasłem dostępu, uwierzytelnianiem przez HTTP, FTP, SSH itp.

W poniższej sekcji, można zdefiniować np. limity transferu i składowania danych, określić folder domowy i domyślny, i wiele innych.

Każdy użytkownik ma domyślnie włączone powiadomienia o przesłanych pakietach danych. Powiadomienia te wysyłane są drogą emailową. Ponieważ produkt nie posiada wbudowanego własnego serwera SMTP należy skonfigurować połączenie z istniejącym korporacyjnym serwerem pocztowym. Dla celów testowych wystarczy utworzyć na platformie Windows Server własną lokalną usługę.

Istotnym elementem wymiany danych są foldery. Z punktu widzenia organizacji, są one podobne do folderów w każdym systemie operacyjnym. W MFT w łatwy sposób można przyporządkowywać poszczególnych użytkowników lub ich grupy, mających do tych folderów dostęp oraz zdefiniować rodzaj dostępu.

Na poniższym rysunku widzimy listę uprawnień, które mogą być dziedziczone od folderu nadrzędnego lub nadane od zera. Oprócz tych najbardziej znanych mamy akcje związane z tworzeniem podkatalogów Sub czy najbardziej ciekawą Share, umożliwiającą udostępnianie tego folderu innym użytkownikom.

Jako administrator możemy określić, jakie uprawnienia dany użytkownik może przydzielić innym użytkownikom współdzieląc katalog. Nierzadko zostawia się tylko ustawienia List i Upload; użytkownik zewnętrzny może wtedy przesłać plik, wylistować zawartość katalogu, ale nie może nic pobrać ani skasować.

Jeśli zostawimy tylko te dwie akcje dla użytkownika testuser, a następnie zalogujemy się na jego konto, widzimy, że może on dodać innych użytkowników do współdzielenia katalogu, ale tylko dla tych wybranych akcji.

Ta użyteczność funkcjonalność nazywa się Secure Folder Sharing i powrócimy do niej w następnym artykule.

Jeśli ktoś nie chce czekać na następny odcinek może poczytać o MOVEit Transfer na stronach Ipswitch np. ipswitch.com, docs.ipswitch.com (cała dokumentacja) czy na stronach Progress Software.

Jeśli ktoś chciałby zobaczyć demo po polsku to proszę pisać na naszym PUG Poland.

Administracja, Info ogólne , ,

Bezpieczeństwo w PASOE cz. II

Część druga bezpieczeństwa w PASOE to raczej tylko suplement, związany z uwierzytelnieniem i autoryzacją użytkowników opartym o dane w plikach tekstowych w podkatalogu serwera aplikacji.

Po pierwsze, autoryzacja użytkowników z pliku users.properites. Każdy z nich ma przypisana rolę np.: ROLE_PSCUser, ROLE_PSCAdmin, ROLE_PSCDebug czy ROLE_None.

Skąd wiadomo, co te role oznaczają i gdzie są zdefiniowane? Żeby się dowiedzieć trzeba otworzyć plik: [working directory]\[instancja pasoe]\webapps\ROOT\WEB-INFF\oeablSecurity.csv.

Pliku oeablSecurity.csv określa kontrolę dostępu do adresów URL dla aplikacji webowych. Każdy wiersz w pliku jest uporządkowanym zestawem trzech wartości.

Odpowiadają one trzem atrybutom elementu przechwytującego URL w Spring Security, a mianowicie:
– wzorzec – wzorzec adresu URL, który może zawierać symbole wieloznaczne i wyrażenia regularne
– metoda – metoda dostępu HTTP
– dostęp – dozwolone role dostępu do zasobu.

Na poniższym obrazku widzimy kontrole dostępu dla poszczególnych warst transportowych. Najpierw APSV (metody HAD, GET, POST) i role, potem SOAP, REST, WEB, a następnie bardziej szczegółowe definicje dla wybranych URI.

Dodajmy, że ustawienia w tym pliku oraz w oeablSecurity.properties znajdują się w kilku lokalizacjach i mają charakter hierarchiczny, np. plik oeablSecurity.csv znajdziemy także w: [working directory]\[instancja pasoe]\conf\oeablSecurity.properties.csv, a oeablSecurity.properties jeszcze w kilku miejscach.

Pliki te bardziej zagnieżdżone dziedziczą ustawienia od plików znajdujących się w podkatalogach powyżej. Dzięki temu można precyzyjnie określić zabezpieczenia dla całej instancji PASOE, aplikacji ABL (agenta wielosesyjnego) czy aplikacji WEB.

Do tej pory podawane przez nas hasła były w postaci jawnej. Co jednak zrobić żeby je zaszyfrować, tak aby haker, który skopiuje pliki z dysku nie miał z nich pożytku?

Sprawa jest bardzo prosta. Po pierwsze zmieniamy nazwę procesu managera uwierzytelniającego dane z local na extlocal.

 

[working directory]\[instancja pasoe]\webapps\ROOT\WEB-INFF\oeablSecurity.properties.

Wartość parametru client.login.model=form lub basic.

Szyfrujemy hasło poleceniem: genspringpwd [hasło], np. genspringpwd password

Otrzymujemy: $2a$09$EU0wp9hga2zmfKBUg21nAeVObPBQQ3erbW53XCcJiQYr8s4QwoCki i tę wartość wstawiamy do pliku users.properites w miejsce jawnego hasła np. dla użytkownika myrestuser.

Restartujemy PASOE i logujemy się wpisując hasło niezaszyfrowane.

Sprawdzamy, że logowanie się powiodło.

Administracja ,

Bezpieczeństwo w PASOE cz. I

Większość nowoczesnych, rozproszonych aplikacji korzysta z serwera aplikacji
dla logiki biznesowej. Korzystanie z serwera PASOE jest bardzo dobrym rozwiązaniem
ponieważ może on bezpośrednio obsługiwać wszystkie typy klientów, jest łatwo skalowalny oraz
może zapewnić bezpieczeństwo aplikacji przy użyciu Spring Security.

Spring Security to framework, który koncentruje się na zapewnianiu uwierzytelniania i autoryzacji dla aplikacji.
Spring Security można rozszerzyć w celu spełnienia niestandardowych wymagań. Poziom bezpieczeństwa zależy od nas, ponieważ to my decydujemy, którą technologię zabezpieczeń wybieramy (lokalne pliki, LDAP, OEREALM, STS i inne).

PASOE zawsze uruchamia Spring Security w sposób domyślny. Nawet próba dostępu do serwisu REST przez użytkownika anonymous wywoła proces uwierzytelniania, autoryzacji i ew. utworzenia tokena Spring Security oraz obiektu ABL CLIENT-PRINCIPAL.

Żeby to zademonstrować, stwórzmy i wystartujmy przykładowy serwer PASOE (ja nazwę go mysec). Od wersji OE12.1 każdy serwer aplikacji startuje serwis ping – jest on dostępny pod adresem URL:
http://localhost:[port]/rest/_oepingService/_oeping


Oznacza to, że PASOE wystartował i mamy dostęp do serwisu ping.

Zobaczmy jakie są domyślne ustawienia dla tego serwisu, który procuje w web aplikacji ROOT. Otwieram plik oeablSecurity.properties w lokalizacji C:\WrkOpenEdge121\mysec\webapps\ROOT\WEB-INF.

Znajdujemy wpis: client.login.model=anonymous.

Oznacza on, że każdy użytkownik (anonymous) ma dostęp do wszystkich aplikacji w ROOT.

Powyżej, widzimy wpis: http.all.authmanager=local. Oznacza on, że uwierzytelnienie jest lokalne w oparciu o użytkowników zdefiniowanych w pliku:
C:\WrkOpenEdge121\mysec\webapps\ROOT\WEB-INFF\users.properites.
Zawartość tego pliku jest następująca:

restuser=password,ROLE_PSCUser,enabled
restdebug=password,ROLE_PSCUser,ROLE_PSCAdmin,ROLE_PSCDebug,enabled
restadmin=password,ROLE_PSCUser,ROLE_PSCAdmin,enabled
restnone=password,ROLE_None,enabled

Chcemy teraz wymusić logowanie ze strony użytkownika – ustawiamy wartość client.login.model=form.
Restartujemy PASOE i ponawiamy dostęp do URL oeping.
Bazując na danych w pliku users.properties wpisujemy: restuser i password. W efekcie dostajemy dostęp do serwisu (patrz. pierwszy rysunek).


Żeby pokazać, że dostaliśmy token od systemu, otwórzmy nową kartę w przeglądarce (ta sama sesja) i wpiszmy URL dla serwisu ping. Dostajemy od razu dostęp, bez logowania.

Jeśli podamy dane restnone i password lub jakiekolwiek inne, nie występujące w pliku, dostęp jest zabroniony.

Dodajmy teraz do pliku users.properties własnego użytkownika, o uprawnieniach takich jak restuser i zmieńmy nazwę na myrestuser.

restuser=password,ROLE_PSCUser,enabled
myrestuser=password,ROLE_PSCUser,enabled
restdebug=password,ROLE_PSCUser,ROLE_PSCAdmin,ROLE_PSCDebug,enabled
restadmin=password,ROLE_PSCUser,ROLE_PSCAdmin,enabled
restnone=password,ROLE_None,enabled

Aby zmiany zostały wczytane, restartujemy PASOE komendą:
pasman pasoestart -v -I mysec -restart

Logujemy się jako nowy użytkownik…

…który ma dostęp do serwisu rest.

O dalszych podstawach zabezpieczeń napiszę w drugiej części.

Administracja ,
1 2 3 4