dotyczy wersji: 8.2; autor: Paweł Jawień
Artykuł zawiera informacje o tym, w jaki sposób zostało skonfigurowane środowisko demonstracyjne dla WEBCON BPS, umożliwiające wykorzystanie wszystkich metod dostępu do realizowanych procesów, oraz wszystkich możliwych sposobów logowania, przy minimalizacji użytych zasobów serwerowych.
Podstawowe założenia:
- System jest zintegrowany z Office 365 i umożliwia startowanie procesów bezpośrednio ze środowiska office 365
- Użytkownik loguje się tylko raz, niezależnie, czy zaczyna pracę w Office 365, czy w środowisku „on-premises”, logowanie odbywa się za pomocą autentykacji wykorzystującej providera autentykacji SAML.
- System jest dostępny na urządzeniach mobilnych.
- System umożliwia również zdalny dostęp bezpośrednio do witryny „on-premises”.
Komponenty systemu:
- Sprzęt
- Dwie maszyny wirtualne
- BPST01.trial.bps – maszyna SharePointowo/bazodanowa. Na jednej maszynie zainstalowany serwer MS SQL 2012 oraz MS SharePoint Foundation 2013
- TRIAL-EDGE.trial.bps – maszyna pełniąca role kontrolera domeny, oraz serwera ADFS zapewniającego zintegrowane logowanie i SSO
- Instancja Office 365 publikujące witrynę https://trialbps.sharepoint.com
- Firewall (FW1) umożliwiający bezpieczną publikację usług w internecie.
- Dwie maszyny wirtualne
- Oprogramowanie
- Windows Server 2012 R2 (na maszynach TRIAL-EDGE i BPST01)
- MS SQL 2012 na maszynie BST01
- MS Sharepoint Foundation 2013 na maszynie BST02
- WEBCON BPS – na maszynie BST01
- Directory Sync – na maszynie BST01, na potrzeby synchronizacji loginów I haseł użytkowników pomiędzy Active Directory „on premises” i Office 365
- Komponenty dodatkowe
- Certyfikat zaufany SSL dla maszyny: BPST01 – adres: https://trial-bps.com
- Certyfikat zaufany SSL dla maszyny: TRIAL-EDGE – adres: https://edge.trial-bps.com
Konfiguracja
Serwery pracują w domenie Active Directory o nazwie NETBIOS: TRIAL (FQDN: trial.bps).
W instalacji działają dwie maszyny:
- trial.bps
- trial-edge.trial.bps
Publiczna domena intenetowa to: trial-bps.com
Serwis WEBCON BPS „on-premises” dla klasycznych przeglądarek jest publikowany na adresie: https://trial-bps.com . Serwis WEBCON BPS dla urządzeń mobilnych jest publikowany na adresie: http://mobile.trial-bps.com
Rozdział adresów wynika z różnych sposobów autentykacji. Dla urządzeń mobilnych wykorzystywany jest mechanizm: NTLM, dla klasycznych przeglądarek zdefiniowano providera autentykacji SAML (na potrzeby integracji z Office 365). W SharePoint zdefiniowano w tym celu odpowiednie adresy alternatywne i odpowiednie strefy, dla których ustawione są różne metody autentykacji – szczegóły opisane w dalszej części artykułu.
Integracja z Office 365
Założenia podstawowe:
Poprawna integracja instalacji WEBCON BPS „on-premises” z Office 365 powinna zapewnić pełną przeźroczystość systemów dla użytkownika. Użytkownik powinien logować się tylko raz, niezależnie, czy loguje się do instalacji „on premises”, czy do Office 365, za pomocą tego samego loginu i tego samego hasła. WEBCON BPS powinien poprawnie rozpoznać użytkownika i wyświetlić mu właściwe zadania do wykonania.
Krok 1 – synchronizacja użytkowników z Active Directory „on premises” do Office 365
Szczegółowy opis synchronizacji katalogów jest dostępny w artykule: https://technet.microsoft.com/pl-pl/library/hh967642
W przedstawionej instalacji narzędzie: Directory Sync jest zainstalowane na maszynie BST01 i zapewnia synchronizację danych wszystkich użytkowników z Office 365.
Krok 2 – przygotowanie sufixu UPN dla domeny trial-bps.com
W opisanej instalacji nazwa domeny Active Directory (FQDN) to: trial.bps, natomiast nazwa publicznej domeny internetowej to: trial-bps.com. Dla poprawnej integracji z office 365 każdy użytkownik powinien mieć suffix UPN zawierający domenę publiczną trial-bps.com
Przed dokonaniem zmiany przykłądaowy użytkownik: Tom Green miał UPN (User Principal Name) w formacie: t.green@trial.bps Aby możliwa była integracja z Office 365, UPN powinien mieć postać: t.green@trial-bps.com
Sposób dodania dodatkowego suffixu UPN opisano w artykule: https://technet.microsoft.com/en-us/library/cc772007.aspx
Dla każdego użytkownika korzystającego z Office 365 należy zmienić suffix domeny.
Po wykonaniu kroków 1 i 2 użytkownicy mogą logować się do Office 365 za pomocą kont Active Directory, ale wciąż logowanie do witryny Office 365 (https://trialbps.shareponit.com) jest niezależne od logowania do witryny „on premises” https://trial-bps.com
Krok 3 – konfiguracja ADFS na potrzeby SSO
Aby zapewnić logowanie jednokrotne do instalacji on premises i Office 365 została zainstalowana i skonfigurowana usługa ADFS (Active Directory Federation Services).
Usługa została skonfigurowana na maszynie: trial-edge.trial.bps. Jest to część systemu operacyjnego Windows Server 2012 R2 i nie wymaga żadnego dodatkowego oprogramowania.
Szczegółowy opis konfiguracji usługi ADFS można znaleźć w artykule: https://technet.microsoft.com/en-us/library/dn486775.aspx
UWAGA! Zanim przystąpimy do konfiguracji, należy przygotować zaufane certyfikaty SSL, w naszym przypadku dla adresu: https://edge.trial-bps.com gdyż pod takim adresem będzie publikowana strona logowania ADFS.
Można przygotować jeden certyfikat zawierający wszystkie potrzebne nazwy alternatywne. W nazym przypadku są to:
Po wstępnej konfiguracji ADFS należy przystąpić do kroku 4
Krok 4 – Konfiguracja autentykacji opartej na providerze SAML dla Sharepointa 2013
Szczegółowy sposób konfiguracji opisany został w artykule:
https://technet.microsoft.com/en-us/library/hh305235.aspx#Phase1
UWAGA! Konieczna będzie zmiana w sekcji:
Create a new authentication provider
Use the procedure in this section to create a new SPTrustedIdentityTokenIssuer.
To create a new authentication provider by using Windows PowerShell
From the Windows PowerShell command prompt, create a new authentication provider, as shown in the following syntax.
| Note: |
| The $realm variable is the name of the relying party trust identifier configured in AD FS, and the $cert variable is the one that was used from the Import a token signing certificate by using Windows PowerShell section. The SignInUrl parameter is to the AD FS server. |
$realm = "urn:sharepoint:<WebAppName>"
$signInURL = "https://<YourADFSServerName>/adfs/ls"
$ap = New-SPTrustedIdentityTokenIssuer -Name <ProviderName> -Description <ProviderDescription> -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $emailClaimMap,$upnClaimMap,$roleClaimMap,$sidClaimMap -SignInUrl $signInURL -IdentifierClaim $upnClaimMap.InputClaimType
Uwaga! W ostatnim poleceniu w części –IdentifierClaim zamieniamy zmienną $emailClaimmap na $upnClaimMap. Jest to związane z faktem, że w instalacji BPS będziemy używać UserPrincipalName do autentykacji
Po wykonaniu wszystkich kroków z podane artykułu (z uwzględnieniem poprawki z skrypcie) instalacja jest prawie gotowa.
Krok 5 – Konwersja domeny lokalnej na sfederowaną z Office 365
Szczegółowy opis tej operacji:
https://technet.microsoft.com/en-us/library/jj205461#BKMK_AddSSDomain
W przypadku instalacji trial-bps, komendy będą miały postać:
$cred=Get-Credential
Connect-MsolService –Credential $cred
Set-MsolAdfscontext -Computer TRIAL-EDGE.TRIAL.BPS
Convert-MsolDomainToFederated –DomainName trial-bps.com
Po poprawnym uruchomieniu podanych komend należy odczekać ok. 15 minut na replikację i proces konfiguracji SSO można uznać za zakończony (prawie).
Użytkownik logując się do office365 zobaczy stronę logowania office 365 (standardowa strona).
Po wpisaniu loginu np. t.green@trial-bps.com użytkownik nie będzie miał możliwości wpisania hasła, lecz zostanie przekierowany na korporacyjną stronę logowania.
Po wpisaniu loginu i hasła domenowego, użytkownik zostanie zautoryzowany zarówno w Office 365, jak i na witrynach „on premises”
UWAGA!
Niestety dla systemu SharePoint użytkownik używający autoryzacji NTLM jest rozróżniany od użytkownika używającego SAML, a dodatkowo w przypadku włączonej autoryzacji SAML pola wyboru użytkowników nie weryfikują poprawności użytkownika (przyjmują każdą wpisaną wartość), należy przeprowadzić dodatkowe czynności.
Przykładowo:
Użytkownik tom Green logując się na witrynie z autentykacją NTLM jest identyfikowany jako:
Natomiast logując się na witrynie z autentykacją SAML jest identyfikowany jako:
Jest to istotne, w przypadku instalacji wykorzystujących obydwa (lub więcej) typy autentykacji. Należy podczas dodawania uprawnień do witryn pamiętać o dodaniu uprawnień dla obydwu typów autentykacji. Po wpisaniu np. imienia użytkownika, któremu chcemy nadać uprawnienia pojawią się dwie pozycje:
Po najechaniu myszą na pozycję pojawi się „ToolTip” informujący, czy jest to użytkownik dla NTLM, czy dla autentykacji SAML.
Aplikacja WEBCON BPS po zainstalowaniu dodatkowego komponentu (opis poniżej) potrafi połączyć te dwa sposoby autentykacji.
Instalacja komponentu WEBCON LDAP Claims Provider
W systemie WEBCON BPS począwszy od wersji 8.2 w katalogu z plikami instalacyjnymi pojawił się nowy katalog o nazwie: „SharePoint”, a w nim podkatalog: „LDAPClaimsProvider”
W katalogu znajduje się skrypt instalacyjny dla komponentu: WEBCON LDAP Claims Provider.
Instalację przeprowadza się na serwerze z zainstalowanym SharePointem. W tym przypadku na BPST01. Należy uruchomić w trybie administratora: SharePoint 2013 Management Shell i z katalogu: LDAPClaimsProvider uruchomić skrypt: Instal_SPS2013.ps1
Skrypt poprosi o wpisanie jednego parametru: sptrust_name:
Jest to nazwa dodatkowego providera autentykacji, który został zdefiniowany wcześniej. W opisywanym przypadku: SAML
Po poprawnej instalacji komponentu, należy przejść do modułu Centralnej Administracji SharePoint do sekcji: „Security”. Pojawiła się tam opcja: WEBCON LDAP Claims Provider
Należy uruchomić sekcję: „Global configuration” i wypełnić parametry:
Domain: należy wpisać nazwę NETBOIS domeny. W opisywanym przypadku: TRIAL
Current LDAP connection – należy podać konto,w kontekście którego, SharePoint łączy się z LDAP, zalecane pozostawienie defaultowej konfiguracji
Z istotnych parametrów można jeszcze wypełnić: Display of permissionns created with identity claim
Należy podać atrybut LDAP, który będzie brany pod uwagę przy wyświetlaniu nazwy użytkownika. Proponowany: displayName.
Pozostałe pola nie wymagają zmian.
W tym momencie system jest w pełni przygotowany do współpracy z Office 365 z jednokrotnym logowaniem.
UWAGA!
Aby zapewnić prawidłowe wyszukiwanie użytkowników w polach typu: „People picker”, należy przejść do sekcji: „Claims mapping” i zweryfikować, czy aktywne jest wyłącznie jedno mapowanie wykorzystujące atrybut LDAP: „userPrincipalName”. W przypadku, gdy aktywne będą inne mapowania np. po adresie email, wówczas podczas wyszukiwania użytkownika będą zwracane dwa wpisy (o ile użytkownik ma wypełniony atrybut: email).
WEBCON BPS w Office 365
Opisana powyżej konfiguracja zapewnia jednokrotne logowanie użytkowników (SSO) zarówno do firmowego portalu Office 365 jak i do instancji SharePoint i WEBCON BPS „on premises”.
Dodatkowo wersja 8.2 systemu WEBCON BPS umożliwia aktywację na witrynie Office 365 webpartów systemu WEBCON BPS umożliwiających:
- Start wybranego procesu
- Podgląd zadań użytkownika na webparcie SWE (lista zadań)
- Ikonę: „Moje zadania” informującą użytkownika o ilości zadań w systemie WEBCON BPS.
Proces instalacji Webpartów WEBCON BPS w Office 365 został opisany w osobnym artykule.
Dostęp dla aplikacji mobilnych
Z uwagi na fakt, że aplikacje mobilne do autentykacji potrzebują NTLM’a, a na witrynie ustawiono autentykację typu SAML, należy dodać dla aplikacji dodatkową zonę (strefę) z dedykowanym adresem alternatywnym.
Szczegółowy opis różnych metod autentykacji w zależności od zdefiniowanych stref jest dostępny w artykule:
https://technet.microsoft.com/en-us/library/cc262350.aspx
W opisywanej instalacji dodano strefę Extranet z alternatywnym adresem: http://mobile.trial-cps.com i dla tej strefy ustawiono autentykację typu NTLM.
