Manual Chapter : Configuring APM as a SAML IdP for Inline SSO

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 15.0.1, 15.0.0
Manual Chapter

Configuring APM as a SAML IdP for Inline SSO

Overview: Configuring APM as a SAML IdP for inline SSO

You can configure the BIG-IP APM system as a Security Assertion Markup Language (SAML) Identity Provider (IdP) to provide inline single sign-on (SSO) for service providers (SP) not directly reachable by the client.
SAML inline SSO is an APM + LTM use case where Service Provider (SP) is located behind BIG-IP as Identity Provider. After the client is authenticated with BIG-IP (configured as IdP), the client's request will reach the protected back-end (configured as a pool), resulting in SP initiated SAML SSO. SP will generate an authentication request which will reach the client and get forwarded to IdP. IdP shall consume authentication request and create "inline" SAML assertion to be sent directly to the SP (bypassing the User-Agent).
Requirements for configuring APM as a SAML IdP for inline SSO
  • The external DNS should point the apps/SP's hostname to the APM. For example, if the internal SP is named app.domain.com, it should resolve to the APM virtual server externally.
  • After configuring the SP connector (preferably with metadata), edit and set its
    SP Location Settings
    to Internal.
  • SSO is configured on Access Profile SSO/Auth Domains configuration page.
  • If using a webtop link, create a webtop link configured with the full URI with the app. For example, using simplesamlphp's default app, the full URI is https://app.domain.com/<default path>/module.php/core/authenticate.php?as=ssPHPSP2. The URL points back to the IdP (https).
The flow is summarized in the following chart.
SP-initiated inline SSO with BIG-IP configured as SAML IdP
SP-Initiated inline SSO with BIG-IP configured as SAML
  1. The user sends a request to https://app.domain.com/page, which resolves to the APM virtual server.
  2. APM asks for credentials by sending its logon page.
  3. The user responds with a username and password, and the APM stores this information in session variables.
  4. APM falls into LTM+APM mode and sends the original request to the SP pool member.
  5. SP responds with its AuthNRequest to the APM as IdP's SAML endpoint.
  6. AuthNRequest goes to the client.
  7. The client sends the AuthNRequest back to the APM for SSO.
  8. APM consumes the AuthNRequest and becomes the user-agent to the SP. This is the result of marking the SP-connector as internal.
  9. APM sends the assertion to the SP's ACS URL.
  10. SP consumes the successful assertion and GETs the app page.
  11. App responds with its page.
  12. SP forwards that response to the APM.
  13. APM forwards the app page to the user's browser.
In a webtop link scenario, the user request will be to / instead of a full URI. The user will be presented with a webtop link. After clicking on the webtop link, a new tab will open, and the request configured in the webtop link will be sent to the SP pool member.

Configuring an access profile for SAML inline SSO

To configure SAML inline SSO, you need to create an access profile to support the LTM-APM profile type with single domain SSO.
  1. On the Main tab, click
    Access
    Profiles / Policies
    .
    The Access Profiles (Per-Session Policies) screen opens.
  2. Click
    Create
    .
    The New Profile screen opens.
  3. In the
    Name
    field, type a name for the access profile.
    A access profile name must be unique among all access profile and any per-request policy names.
  4. From the
    Profile Type
    list, select
    LTM-APM
    .
    Additional settings display.
  5. From the
    Profile Scope
    list, select the appropriate scope to grant to users being examined by this policy.
  6. In the SSO Across Authentication Domains (Single Domain mode) area:
    1. Retain default settings for
      Domain Cookie
      (blank) and
      Cookie Options
      (with only the
      Secure
      check box selected).
    2. From
      SSO Configuration
      , select the SSO configuration to apply to the domain.
  7. In the Language Settings area, add and remove accepted languages, and set the default language.
    A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
  8. Click
    Finished
    .
    This creates an access profile with a default access policy.
The access profile displays in the Access Profiles List. Default-log-setting is assigned to the access profile.

Creating a virtual server for SAML inline SSO

Before you start this task, configure a client SSL profile and a server SSL profile.
Specify a host virtual server to use as the SAML IdP.
  1. On the Main tab, click
    Local Traffic
    Virtual Servers
    .
    The Virtual Server List screen opens.
  2. Click
    Create
    .
    The New Virtual Server screen opens.
  3. In the
    Name
    field, type a unique name for the virtual server.
  4. In the
    Destination Address
    field, type the IP address for a host virtual server.
    This field accepts an address in CIDR format (IP address/prefix). However, when you type the complete IP address for a host, you do not need to type a prefix after the address.
  5. In the
    Service Port
    field, type
    443
    or select
    HTTPS
    from the list.
  6. For the
    HTTP Profile
    setting, verify that the default HTTP profile,
    http
    , is selected.
  7. For the
    SSL Profile (Client)
    setting, from the
    Available
    list, select the name of the Client SSL profile you previously created and move the name to the
    Selected
    list.
  8. For the
    SSL Profile (Server)
    setting, from the
    Available
    list, select the name of the Server SSL profile you previously created and move the name to the
    Selected
    list.
  9. In the Access Policy area, from the
    Access Profile
    list, select the access profile that you configured earlier.
  10. In the Resources area of the screen, from the
    Default Pool
    list, select the pool containing the service provider IP address.
  11. Click
    Finished
    .
The virtual server for the BIG-IP system configured for SAML inline SSO now appears on the Virtual Server List.

Tasks to complete SAML inline SSO

The steps to finish configuring APM as a SAML Identity Provider (IdP) for SAML inline SSO (or SAML multi-domain inline SSO) are included in the section
Using APM as a SAML IdP (SSO portal)
, which appears in the
SAML Configuration
guide.
  • Configuring an artifact resolution service
  • Configuring SAML SP connectors
  • Configuring a SAML IdP service for one SP connector
  • Binding a SAML IdP service to one SP connector
  • Exporting SAML IdP metadata from APM
  • Configuring a SAML resource and attaching a SAML IdP service
  • Configuring an access policy for a SAML SSO portal
  • Adding IdP metadata from APM to external SAML SPs

Overview: Configuring APM as a SAML IdP for multi-domain inline SSO

You can configure multi-domain inline SAML SSO when multiple service providers (SPs) are located behind different virtual servers. All SPs share a single access profile with SAML assertions generated on request by the Identity Provider (IdP).
A user can connect to any of the SPs protected by the virtual servers in the domain group and be authenticated by the IdP. Subsequent connections to other SPs within the domain group do not require users to authenticate.
As a result, inline SAML SSO with multi-domain deployment behaves as follows:
  • IdP objects assigned in a multi-domain access policy (either in a Resource Assign agent or in an advanced Resource Assign Agent) are applied to requests from all authentication domains.
  • When the Cookie Scope for the application virtual in the multi-domain SSO is set to Domain, the system also uses the SSO configuration (IdP object) created for that domain in the SSO Config attribute, provided the primary authentication URI is in the same domain.
  • When the Cookie Scope for the application virtual in the multi-domain SSO is set to Host, the system ignores the SSO Config created for that host when processing authentication requests from an internal SP. This is because SAML authentication requests are processed by the primary authentication virtual hosting the IdP. Instead, IdP objects assigned in an access policy for primary authentication URI will be applied when processing authentication requests from internal SP.
The flow is summarized in the following chart.
SP-initiated multi-domain inline SAML SSO
SP-initiated multi-domain inline SAML SSO
1. The user attempts to access the resource
app1.domain.com
located on virtual server
1(VIP1)
, protected by the BIG-IP APM system.
2.
VIP1
is configured for multi-domain SSO and redirects the user to the Primary Authentication URI for authentication.
3. The IdP authenticates the user.
4. After successful authentication, the user is redirected back to
VIP1
.
5 - 6.
VIP1
load balances the user request and directs it to one of the pool members.
7. Because the user does not have a valid session, the internal SP (or SAML enabled application) initiates SAML SSO by generating an AuthRequest and redirects the user to IdP.
8 - 9. The authentication request is forwarded through the user-agent to IdP (
idp.domain.com
).
10. The IdP consumes and validates the authentication request. Upon successful validation, a new SAML assertion and token are generated. The assertion is stored in the session database, and the token
SAMLtoken
is sent back to the client through the HTTP-Redirect binding. The location of the original virtual is derived from the
Referer
header of request 8.
11 - 12. The user is redirected back to the application virtual server together with the
SAMLtoken
.
13 - 14.
VIP1
consumes the
SAMLtoken
request and modifies the client request to inject a SAML assertion inline.
15.
app1.domain.com
validates and consumes the assertion.
16 - 17. Upon successful validation of the assertion, the application content is served to the user.
18 - 19. Because the user-agent already has a valid cookie for
domain.com
, the user request (18) is allowed to reach the pool member SP2
app2.domain.com
.
20. However, since
app2.domain.com
does not have a valid session with the client, an authentication request is generated by the SP2
app2.domain.com
.
21 - 22. The authentication request reaches IdP through the user-agent.
23 - 30. This sequence is similar to 10 through 17.

Creating an access profile for SAML multi-domain inline SSO

To configure SAML multi-domain inline SSO, you need to create an access profile to support the LTM-APM profile type with multi-domain SSO.
  1. On the Main tab, click
    Access
    Profiles / Policies
    .
    The Access Profiles (Per-Session Policies) screen opens.
  2. Click
    Create
    .
    The New Profile screen opens.
  3. In the
    Name
    field, type a name for the access profile.
    A access profile name must be unique among all access profile and any per-request policy names.
  4. From the
    Profile Type
    list, select
    LTM-APM
    .
    Additional settings display.
  5. From the
    Profile Scope
    list, select the appropriate scope to grant to users being examined by this policy.
  6. In the Language Settings area, add and remove accepted languages, and set the default language.
    A browser uses the highest priority accepted language. If no browser language matches the accepted languages list, the browser uses the default language.
  7. Click
    Finished
    .
    This creates an access profile with a default access policy.
  8. From the list, click the name of the access profile you just created.
  9. On the menu bar, click
    SSO/Auth Domains
    .
  10. For the
    Domain Mode
    setting, select
    Multiple Domains
    .
  11. For
    Primary Authentication URI
    , type the URI to the IdP, for example,
    http://idp.domain.com
    .
    Each domain that you configure indicates the domain to which the APM session (established by the primary authentication URI) is bound.
  12. In the Authentication Domain Configuration area, for
    Cookie
    , select
    Host
    or
    Domain
    , and for the host, type the IP address, or for domain, type the fully qualified domain name.
  13. Configure the
    Cookie Options
    .
    The default is
    Secure
    .
    When
    Cookie Scope
    for application virtual servers in a multi-domain SSO is set to
    Domain
    , the BIG-IP system also uses the SSO configuration (IdP object) configured for that domain in the SSO Config attribute, provided that the
    Primary Authentication URI
    is in the same domain.
    When
    Cookie Scope
    for application virtual servers in a multi-domain SSO is set to
    Host
    , the BIG-IP system ignores the SSO Config (IdP object) for that host when processing authentication requests from the internal SP; SAML authentication requests are processed by the primary authentication virtual server hosting the IdP. Instead, IdP objects assigned in the access policy and access profile for the
    Primary Authentication URI
    are applied when processing authentication requests from the internal SP.
  14. From
    SSO Configuration
    , select the configuration that you want to associate with each host or domain.
  15. Click
    Update
    .
The access profile is created and updated for multi-domain inline SSO.

Creating a virtual server for SAMLmulti-domain inline SSO

Before you start this task, configure client and server SSL profiles.
You need to create virtual servers for every domain to support SAML multi-domain inline SSO.
  1. On the Main tab, click
    Local Traffic
    Virtual Servers
    .
    The Virtual Server List screen opens.
  2. Click
    Create
    .
    The New Virtual Server screen opens.
  3. In the
    Name
    field, type a unique name for the virtual server.
  4. In the
    Destination Address
    field, type the IP address for a host virtual server.
    This field accepts an address in CIDR format (IP address/prefix). However, when you type the complete IP address for a host, you do not need to type a prefix after the address.
  5. In the
    Service Port
    field, type
    443
    or select
    HTTPS
    from the list.
  6. For the
    HTTP Profile
    setting, verify that the default HTTP profile,
    http
    , is selected.
  7. For the
    SSL Profile (Client)
    setting, from the
    Available
    list, select the name of the Client SSL profile you previously created and move the name to the
    Selected
    list.
  8. For the
    SSL Profile (Server)
    setting, from the
    Available
    list, select the name of the Server SSL profile you previously created and move the name to the
    Selected
    list.
  9. In the Access Policy area, from the
    Access Profile
    list, select the access profile that you configured earlier.
  10. Click
    Finished
    .
The virtual server is created. You need to create a similar virtual server for any other domains.

Tasks to complete SAML inline SSO

The steps to finish configuring APM as a SAML Identity Provider (IdP) for SAML inline SSO (or SAML multi-domain inline SSO) are included in the section
Using APM as a SAML IdP (SSO portal)
, which appears in the
SAML Configuration
guide.
  • Configuring an artifact resolution service
  • Configuring SAML SP connectors
  • Configuring a SAML IdP service for one SP connector
  • Binding a SAML IdP service to one SP connector
  • Exporting SAML IdP metadata from APM
  • Configuring a SAML resource and attaching a SAML IdP service
  • Configuring an access policy for a SAML SSO portal
  • Adding IdP metadata from APM to external SAML SPs