This article contains information on how to correctly configure the demonstrational environment of WEBCON BPS. This trial has been designed to include every possible way of accessing available business processes along with every possible login method, whilst keeping server usage to a minimum.
- The system is integrated with Office 365 and allows processes to be started directly from there.
- The user only needs to log in once, regardless of whether they began the trial from Office 365 or on-premises. Authentication carried out via SAML.
- System is available on mobile devices
- System allows for remote access directly to the trial.
- Two virtual machines
- BPST01.trial.bps – SharePoint/Database machine. This machine has both MS SQL 2012 and MS SharePoint Foundation 2013 installed.
- TRIAL-EDGE.trial.bps – This machines serves as the domain controller, and as a ADFS server for integrated login and SSO.
- Office 365 to publish the following site: https://trialbps.sharepoint.com
- Firewall (FW1) for publishing content on the internet safely.
- Two virtual machines
- Windows Server 2012 R2 (on TRIAL-EDGE and BPST01)
- MS SQL 2012 (on BST01)
- MS SharePoint Foundation 2013 (on BST02)
- WEBCON BPS (on BST01)
- Directory Sync (on BST01), To synchronize user logins and passwords between the on-premises Active Directory and Office 365.
- Additional components
Servers are part of an Active Directory domain called NETBIOS: TRIAL (FQDN: trial.bps).
Two machines take part in the installation:
The public internet domain is: trial-bps.com
The on-premises WEBCON BPS service for classic web browsers is published under the following address: https://trial-bps.com .
The WEBCON BPS service for mobile devices can be found here: http://mobile.trial-bps.com
Different addresses are necessary due to different types of authentication: mobile devices use NTML, classic browsers have a SAML provider (for integration with Office 365). The SharePoint site was prepared for this, with alternative custom addresses and zones, which use different authentication methods – this will be mentioned further down the article.
Integration with Office 365
Correct integration of WEBCON BPS “on-premises” with Office 365 should provide full system transparency to the user. The user should be required to log in only once, either “on-premises” or in Office 365, with one login and password. WEBCON BPS should then correctly identify the user and display them their assigned tasks.
Step 1 – Synchronizing users from an on-premises Active Directory environment with Office 365
A detailed description of directory synchronization is found here:
In this example, the tool: Directory Sync is installed on BST01 and enables synchronizing the data of all users with Office 365.
Step 2 – Preparing a UPN suffix for the trial-bps.com domain
For this installation process, the Active Directory domain name (FQDN) is: trial.bps, whereas the public internet domain is: trial-bps.com. To correctly integrate with Office 365 every user should have a UPN suffix containing the public domain trial-bps.com
As an example, the user: Tom Green had a UPN (User Principal Name) in the following format: firstname.lastname@example.org , For integration with Office 365 to be possible, the UPN should look like this: email@example.com
Adding UPN suffixes has been described here: https://technet.microsoft.com/en-us/library/cc772007.aspx
Every user using Office 365 should have their domain suffix changed.
After completing steps 1 and 2, users will be able to log into Office 365 using their Active Directory accounts.
Step 3 – Configuring ADFS for SSO purposes
To ensure that only a single log in is required, in addition to the on-premises installation and Office 365, an ADFS (Active Directory Federation Services) type service was installed and configured.
This service was configured on the trial-edge.trial.bps machine. It is a part of the Windows Server 2012 R2 operating system and doesn’t require any additional software.
A detailed description of the ADFS service configuration can be found here: https://technet.microsoft.com/en-us/library/dn486775.aspx
WARNING! Before attempting to configure the settings, be sure to prepare trusted SSL certificates, in this case for the following address: https://edge.trial-bps.com (ADFS log in site).
It is possible to prepare a single certificate containing all needed names, in this case they are:
After configuring ADFS, continue to step 4
Step 4 – Configuring authentication based on SAML for SharePoint 2013
Configuration has been described in detail in the following article:
WARNING! It is necessary to make a modification in:
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.
|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
Warning! In the last part under –IdentifierClaim change the variable $emailClaimmap to $upnClaimMap. This is because during BPS Installation, UserPrincipalName is used for authentication.
After completing the above steps, including the slight modification in the script, the installation is almost ready.
Step 5 – Federating the local domain with Office 365
Detailed description of this process:
When installing trial-bps, the commands will look something like this:
Connect-MsolService –Credential $cred
Set-MsolAdfscontext -Computer TRIAL-EDGE.TRIAL.BPS
Convert-MsolDomainToFederated –DomainName trial-bps.com
After successfully launching the above commands and waiting roughly 15 minutes, the SSO configuration process can be considered (almost) finished.
A user logging into Office 365 will see the standard Office 365 site.
By entering a login like firstname.lastname@example.org the user will not be able to enter a password, they will be redirected to the corporate log-in site instead.
After entering a domain login and password, the user will be authorized for both Office 365 as well as „on premises” sites.
Unfortunately, the SharePoint system treats users using NTLM and SAML authentication differently. Additionally, when users authenticated via SAML make changes in choice fields, their credentials aren’t checked (the values are accepted automatically) – additional action is needed.
User Tom Green logs in to a site using NTLM authentication, he is identified as:
Whereas logging into a site with SAML authentication will cause him to be recognized as:
It is important to keep this in mind when using two (or more) types of authentication. When defining privilege settings for a site, remember to take both types into account and add the relevant privileges. After entering the name of the user whose privileges we wish to modify, autocomplete should suggest two positions:
Mousing over either of these names will bring up a “Tooltip” with information on which is the NTML, and which is the SAML user.
WEBCON BPS can be supplemented with an additional component to combine these two methods of authentication. The Installation of this component has been described below:
Installing the WEBCON LDAP Claims Provider component
Starting with version 8.2, the WEBCON BPS installation files catalogue contains a new folder named: “SharePoint”, inside is another folder named: “LDAPClaimsProvider”.
“LDAPClaimsProvider” contains an installation script for the component: WEBCON LDAP Claims Provider.
The installation process is carried out on the machine with SharePoint installed. In our case, it is on BPST01. Run SharePoint 2013 Management Shell as an administrator. From the LDAPClaimsProvider folder launch the script: Instal_SPS2013.ps1
The script will request one parameter: sptrust_name:
It is the name of an additional authentication provider, which has been added earlier. In our case it is SAML.
After correctly installing the component, go to SharePoint’s Central Administration module, by clicking on “Security” you will notice a new, 4th option: WEBCON LDAP Claims Provider
Choose the ”Global configuration” section and fill out these parameters:
Domain: Enter the domain’s NETBIOS name. In this case, it is: TRIAL
Current LDAP connection – Enter the username through which SharePoint connects with LDAP, it is recommended to leave the default settings in place.
It may also be worthwhile to fill out: Display of permissions created with identity claim
Enter the LDAP attribute which will be taken into account when displaying a username. Recommended: displayName.
Other fields are irrelevant to us for now.
The system is finally fully prepared for cooperation with Office 365 and Single-Sign On
In order to ensure that queries correctly find specific users in fields like “People picker”, navigate to the “Claims mapping” section and make sure that only mapping by LDAP field: “userPrincipalName” is enabled. If any other mode of mapping is active, (ex. by e-mail address) a search will return 2 results (if that user has a valid entry in the “email” field).
WEBCON BPS in Office 365
The configuration described above enables users to log in once (SSO) and access the Office 365 and SharePoint sites as well as WEBCON BPS “on premises”.
Additionally, WEBCON BPS 8.2 allows WEBCON BPS Web Parts to be used on the Office 365 site enabling:
- Starting a chosen process.
- Overview of a user’s tasks on a SWE Web Part (Task list)
- My tasks icon, which tells the user how many active tasks they have in WEBCON BPS.
The installation process for WEBCON BPS Web Parts in office 365 will be described in a separate article.
Since mobile applications need NTLM, and the site is using SAML authentication, it is necessary to create a separate zone with a custom alternative address.
A detailed article describing how to plan out zones for various methods of authentication can be found here:
For the purposes of our demonstration, an additional zone named Extranet was added under the custom address: http://mobile.trial-cps.com. This zone uses of NTML authentication.