Choosing a deployment model¶
Authentication¶
Depending on your existing authentication model, you have to choose between a SAML based (“Federation portal”) or a multi-domain based deployment (“Multi-Domain portal”).
In a SAML based deployment, each of your web applications will act as a SAML SP reaching out to an external SAML IDP.
In a multi-domain based deployment, the user session will be “extended” to the all of the domains or Fully Qualified Domain Names (FQDNs) defined in the Access Profile.
Please refer to https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-access-policy-manager-single-sign-on-concepts-configuration/single-sign-on-and-multi-domain-support.html for further information on multi-domain deployment.
Publishing¶
If you only have to deploy a few applications, it can be easier to manually configure each of them on a dedicated Virtual Server, with its own Per-Request Policy and configuration objects (SSL profiles, SSO profile etc…). In this document, we will refer to this deployment method as “Single-app deployment”.
However, once the number of applications to publish crosses a certain threshold, manual deployment becomes a maintenance burden and does not scale as well as having a single Virtual Server dynamically adjusting its configuration to accommodate all of the applications. This deployment is referenced later in this document as “Multi-app deployment”.
Prerequisites¶
Within this document, we will use the following notation to refer to the actual addresses needed to configure the web applications:
<client-side-fqdn>: this is the fully-qualified hostname that the client browser uses to reach the BIG-IP APM virtual server. For example: app1.company.com<server-side-fqdn>: this is the fully-qualified hostname that the web server or the web application uses internally to refer to itself. For example: app1.intranet.local<logout-uri>: this is the URL that the client browser uses to trigger a logout of the application.
Federation portal¶
Description¶
Using a SAML based Federation portal provides the BIP-IP APM administrator with the most flexible solution.
The authentication is performed by either a local or remote SAML IDP policy indifferently.
Each application is served out of its own or a shared SAML SP policy which allows to easily implement varying security policies depending on the nature of the application being served. Also, each application access is using a dedicated BIG-IP APM session which provides additional auditing granularity.
Last, SAML allows to securely share and re-use credentials between the IDP and the SP - if needed - for SSO purposes.
Implementation of a SAML based Federation portal¶
Describing the implementation of a SAML based Federation portal is beyond the scope of this document.
Please refer to BIG-IP APM manual and operations guide to implement this configuration:
Multi-Domain portal¶
Description¶
The Multi-Domain portal is a simple configuration which allows the BIG-IP APM administrator to share user sessions across multiple domains (or Fully Qualified Domain Names to be more precise). A user without an existing session is redirected to the Primary authentication Virtual Server where he authenticates before being redirected back to his original destination. A user accessing the Primary authentication Virtual Server can be presented with a webtop on which links to other Virtual Servers can be displayed.
Modifying an existing Access Profile to add Muti-Domain support¶
Go to Access ›› Profiles / Policies : Access Profiles (Per-Session Policies), click on the policy to be modified. When transitioning from Portal Access, the Access Policy which currently provides the Webtop and Portal Access resources is the logical choice, unless you choose to create a separate setup for this deployment.
Click the “SSO / Auth Domains” tab.
Click Domain Mode: “Multiple Domains” and fill in the public facing URL for the Virtual Server to which this policy is currently attached.
Example: https://auth.company.com
Click “Update”
Note: An SSO credential mapping agent is needed in the policy in order to be able later, to use SSO objects attached to the app VS.
Single-app deployment¶
Use case description¶
In this deployment, the web application is going to be delivered on its own virtual server, just like a regular BIG-IP LTM load-balanced website. BIG-IP APM Per-Session and Per-Request policies are added to authenticate users and rewrite the Host and Referer headers. The per-request policy also includes a logout mechanism triggered when BIG-IP APM receives the configured logout URL.
Features¶
Rewrites Host and Referer headers.
Clears APM related cookies before sending requests to back-end server.
Supports a logout URI.
Supports SSO.
Supports client-side HTTP/2.
Limitations¶
Logout is triggered immediately when BIG-IP detects the HTTP request configured for the logout. This request does not reach the back-end server.
Each application requires its own virtual server and its own per-request policy.
Favicon requests are blocked until the user is authenticated which may prevent the correct display of an application’s icon in users’s bookmarks.
Application setup¶
Define and create the required configuration items for the app¶
SSL profiles
Client-ssl profile
A new client-ssl profile needs to be created with a certificate/key pair matching the FQDN of the virtual server on which the application will be published (ie:
<client-side-fqdn>).
Server-ssl profile
If the server-side application requires an SSL connection, a server-ssl profile will be needed.
SSO
If the server-side application needs to have Single Sign On enabled, the corresponding SSO object should be created.
Logout URI
The URL that will trigger the BIG-IP APM session logout needs to be determined based on the web application’s behaviour when performing its own logout process.
Per-Request policy¶
Create a new Per-request policy
Click the “Edit Endings” button and modify the “Reject” ending to be:
“Logout redirect”, “redirect”, “https://
<client-side-fqdn>/”, “Close session after redirect”
Add a new item to branch the policy based on the URL:
Click the “+” sign, select the “Classification” tab, click “URL Branching”, then “Add Item”.
Configure the URL Branching item:
Name: “Detect Logout URI”
Delete existing branch.
Add Branch Rule:
Name: “Logout URI”
Context: “URL Branching”
Condition: “Equals”
URL is: “https://
<client-side-fqdn>/<logout-uri>”
Change the “Fallback” branch ending to “Allow”.
Add a new item to modify HTTP Headers:
On the fallback branch, click the “+” sign, select the “General Purpose” tab, click “HTTP Headers”, then “Add Item”.
Configure HTTP Headers:
Add 2 “HTTP Header Modify” entries with the following values:
“replace”, “Referer”, “http(s)://
<server-side-fqdn>”“replace”, “Host”, “
<server-side-fqdn>”
Add 2 “HTTP Cookie Modify” entries with the following values:
“delete”, “MRHSession”
“delete”, “LastMRH_Session”
Add a new item to set the SSO method:
On the fallback branch, click the “+” sign, select the “General Purpose” tab, click “SSO Configuration Select”, then “Add Item”.
Configure SSO:
Select the appropriate SSO object for the app.
Per-request policy completed¶
Access profile and Per-Session Access policy¶
Assign the policy created in the earlier Federation portal or Multi-domain portal section of this document.
Virtual Server¶
Create a new Virtual Server
Assign the following profiles:
Client-ssl
Server-ssl if appropriate
Http
Source Address Translation
Access profile
Per-Request Policy
Note: If using a Multi-Domain portal, this new Virtual Server will need to be set with all the required profile as mandated by the attached Access profile (for example: Rewrite and or Connectivity profiles)
Create and attach a pool pointing at the server-side app
Publish the app¶
Update DNS records to ensure that
<client-side-fqdn>points at the virtual server’s IP.Create a Webtop link or a SAML link and assign that resource to appropriate users using the VPE for the Access Policy deployed.
If using a Multi Domain portal, register the client-side FQDN (
<client-side-fqdn>) in the authentication Virtual Server’s Access Policy:Go to Access ›› Profiles / Policies : Access Profiles (Per-Session Policies), click on the Multi Domain policy’s name.
Click the “SSO / Auth Domains” tab.
Add a new “Authentication Domain”:
Cookie: “Host” /
<client-side-fqdn>
Note: SSO does not have to be selected as it is being set by the PRP policy.
Multi-app deployment¶
Use case description¶
When deploying many web applications, it would be inconvenient to have to create and maintains as many virtual servers and per-request access policies as there are web applications deployed. This deployment scenario uses a Data Group and an iRule to dynamically configure a single virtual server with the right objects and rewriting rules depending on the hostname (or more precisely, the FQDN) that the client browser uses to access the virtual server.
Features¶
Dynamic pool and profiles assignments based on SNI hostname matching against a site definition list.
Rewrites Host and Referer headers.
Clears APM related cookies before sending requests to back-end server.
Supports favicon.ico
Supports delayed logout URI patterns.
Supports SSO and ACL.
Supports client-side HTTP/2.
Initial setup¶
Create the configuration Data Group¶
Go to “Local Traffic”, “iRules” / “Data Group list”, click “Create”:
Name: “sites2publish-dg”
Type: “String”
Create the first entry in the Data Group to use later as a format reference:
String: “%Documentation%”
Value: “http|https,backend_fqdn,pool_name,clientssl_profile,acl_name,sso_name,logout_uri”
Create the iRule¶
Create a new iRule with the code from the following link: iRule for Multi-app deployment
Configure (or create) the Virtual Server for all applications¶
Assign a default client ssl profile.
Assign a server ssl profile.
Note: Always assign a server ssl profile, even if none of the back-end servers require SSL.
Assign an Access Profile: assign the policy created in the earlier Federation portal or Multi-domain portal section of this document.
If you are using a Federation portal: Assign the SAML SP policy.
If you are using a Multi Domain portal: Assign the same policy as set on the Primary Authentication VS.
Assign the irule created earlier.
Note: If using a Multi-Domain portal, this new Virtual Server will need to be set with all the required profile as mandated by the attached Access profile (for example: Rewrite and or Connectivity profiles)
Applications setup¶
Note: This procedure needs to be performed for each app.
Create or select configuration components to be applied to the app¶
ACL (Access ›› Access Control Lists : User-defined ACLs).
SSO method (Access ›› Single Sign-On).
Pool (Local Traffic ›› Pools : Pool List).
Client-SSL profile (Local Traffic ›› Profiles : SSL : Client).
Define the app’s configuration¶
SNI or Client-side FQDN (
<client-side-fqdn>).Protocol (choose between “http” and “https”).
Application’s Server-side FQDN (
<server-side-fqdn>).Logout URI pattern.
Note: this pattern is used to verify a match between the requested URI (HTTP::uri) and the configured pattern using the iRule “matches_glob” command. Once a request matches the pattern, a logout is triggered after the delay set in the irule by the variable “static::LOGOUT_DELAY” (value is in milliseconds).
Register the app’s configuration¶
Update the Data Group:
Go to “Local Traffic”, “iRules” / “Data Group list”, click “sites2publish-dg”.
Add a new entry with:
String:
<client-side-fqdn>Value:
[http|https],<server-side-fqdn>,pool_name,clientssl_profile,acl_name,sso_name,logout_uri
Example:
String: app3.cl.lab.test
Value: https,app3.srv.lab.test,/Common/srv-gw-https,/Common/app3-clientssl,/Common/app3-acl1,,/debug.php?*logout=true
Note: Unused optional configuration objects can be left empty in the configuration string of the data group entry. In the example above, no SSO object was associated with this application.
Publish the app¶
Note: This procedure needs to be performed for each app.
Update DNS records to ensure that
<client-side-fqdn>points at the virtual server’s IP on which the iRule is applied.Create a Webtop link or a SAML link and assign that resource to appropriate users using the VPE for the Access Policy deployed.
If using a Multi Domain portal, register the client-side FQDN (
<client-side-fqdn>) in the authentication Virtual Server’s Access Policy:Go to Access ›› Profiles / Policies : Access Profiles (Per-Session Policies), click on the Multi Domain policy’s name.
Click the “SSO / Auth Domains” tab.
Add a new “Authentication Domain”:
Cookie: “Host” /
<client-side-fqdn>
Note: SSO does not have to be selected as it is being set later either by iRule or PRP policy.