F5 BIG-IP Access Policy Manager (APM) - Google Authenticator and Microsoft Authenticator
Introduction Lab guide Phase 1: Token Generation Phase 2: Token verification Related Content Introduction In our walkthrough we are refreshing an existing time-based one-time password (TOTP) deployment Two-Factor Authentication With Google Authenticator And APM In our walkthrough we are following the below assumptions, Secret key is generated outside of F5 and saved to Active Directory (AD) user attribute. F5 APM should be able to query AD user attribute (for example, in our case it's called serialNumber). We have two separate portals, One portal for Token generation and QR scanning. One portal for Application access. Lab guide Phase 1: Token Generation User logs in to the token generation portal and authenticates with AD credentials. F5 APM authenticates the user with AD and query the attribute for the secret key. F5 APM presnets the QR code for the user to be scanned whether by Google or Microsoft Authenticators. Phase 2: Token verification User Access the application and authenticates with AD credentials. Once user is successfully authenticated, the user is prompted to provide the one-time password (OTP). Once F5 verifies the provided OTP, the user is allowed to access the application. Verification iRule when ACCESS_POLICY_AGENT_EVENT { if { [ACCESS::policy agent_id] eq "ga_code_verify" } { ### Google Authenticator verification settings ### # lock the user out after x attempts for a period of x seconds set static::lockout_attempts 3 set static::lockout_period 30 # logon page session variable name for code attempt form field set static::ga_code_form_field "ga_code_attempt" # key (shared secret) storage method: ldap, ad, or datagroup set static::ga_key_storage "ad" # LDAP attribute for key if storing in LDAP (optional) set static::ga_key_ldap_attr "google_auth_key" # Active Directory attribute for key if storing in AD (optional) set static::ga_key_ad_attr [ACCESS::session data get "session.ad.last.attr.serialNumber"] # datagroup name if storing key in a datagroup (optional) set static::ga_key_dg "google_auth_keys" ##################################### ### DO NOT MODIFY BELOW THIS LINE ### ##################################### # set lockout table set static::lockout_state_table "[virtual name]_lockout_status" # set variables from APM logon page set username [ACCESS::session data get session.logon.last.username] set ga_code_attempt [ACCESS::session data get session.logon.last.$static::ga_code_form_field] # retrieve key from specified storage set ga_key "" switch $static::ga_key_storage { ldap { set ga_key [ACCESS::session data get session.ldap.last.attr.$static::ga_key_ldap_attr] } ad { set ga_key [ACCESS::session data get "session.ad.last.attr.serialNumber"] } datagroup { set ga_key [class lookup $username $static::ga_key_dg] } } # increment the number of login attempts for the user set prev_attempts [table incr -notouch -subtable $static::lockout_state_table $username] table timeout -subtable $static::lockout_state_table $username $static::lockout_period # verification result value: # 0 = successful # 1 = failed # 2 = no key found # 3 = invalid key length # 4 = user locked out # make sure that the user isn't locked out before calculating GA code if { $prev_attempts <= $static::lockout_attempts } { # check that a valid key was retrieved, then proceed #Update the key length based on the organization requirements if { [string length $ga_key] == 16 } { # begin - Base32 decode to binary # Base32 alphabet (see RFC 4648) array set static::b32_alphabet { A 0 B 1 C 2 D 3 E 4 F 5 G 6 H 7 I 8 J 9 K 10 L 11 M 12 N 13 O 14 P 15 Q 16 R 17 S 18 T 19 U 20 V 21 W 22 X 23 Y 24 Z 25 2 26 3 27 4 28 5 29 6 30 7 31 } set ga_key [string toupper $ga_key] set l [string length $ga_key] set n 0 set j 0 set ga_key_bin "" for { set i 0 } { $i < $l } { incr i } { set n [expr $n << 5] set n [expr $n + $static::b32_alphabet([string index $ga_key $i])] set j [incr j 5] if { $j >= 8 } { set j [incr j -8] append ga_key_bin [format %c [expr ($n & (0xFF << $j)) >> $j]] } } # end - Base32 decode to binary # begin - HMAC-SHA1 calculation of Google Auth token set time [binary format W* [expr [clock seconds] / 30]] set ipad "" set opad "" for { set j 0 } { $j < [string length $ga_key_bin] } { incr j } { binary scan $ga_key_bin @${j}H2 k set o [expr 0x$k ^ 0x5C] set i [expr 0x$k ^ 0x36] append ipad [format %c $i] append opad [format %c $o] } while { $j < 64 } { append ipad 6 append opad \\ incr j } binary scan [sha1 $opad[sha1 ${ipad}${time}]] H* token # end - HMAC-SHA1 calculation of Google Auth hex token # begin - extract code from Google Auth hex token set offset [expr ([scan [string index $token end] %x] & 0x0F) << 1] set ga_code [expr (0x[string range $token $offset [expr $offset + 7]] & 0x7FFFFFFF) % 1000000] set ga_code [format %06d $ga_code] # end - extract code from Google Auth hex token if { $ga_code_attempt eq $ga_code } { # code verification successful set ga_result 0 } else { # code verification failed set ga_result 1 } } elseif { [string length $ga_key] > 0 } { # invalid key length, greater than 0, but not length not equal to 16 chars set ga_result 3 } else { # could not retrieve user's key set ga_result 2 } } else { # user locked out due to too many failed attempts set ga_result 4 } # set code verification result in session variable ACCESS::session data set session.custom.ga_result $ga_result } } Related Content Two-Factor Authentication With Google Authenticator And APM Demystifying Time-based OTP Google Authenticator Token Verification iRule For APM APM Google Authenticator HTTP API Google Authenticator Verification iRule (TMOS v11.1+ optimized) UDF Lab Configuring MFA OTP Note, Scan the Article photo for more BIG-IP Access Policy Manager (APM) info.OAuth and OpenID Connect - Made easy with Access Guided Configurations templates
Introduction Lab walk through Access Guided Configuration support Lab steps summary Create DNS Resolver. From Access Guided configuration choose proper template. Create OAuth Provider. Create OAuth Server. Create OAuth Policy (Scope). Create Virtual Server. Optional: Single Sign-On configurations. Lab configurations steps Create DNS Resolver Access Guided configuration template Create OAuth Provider, Server and Policy Create Virtual Server Introduction OpenID Connect (OIDC) is an open authentication protocol that works on top of the OAuth 2.0 framework. The purpose of OIDC is for users to provide one set of credentials and access multiple sites. Each time users sign on to an application or service using OIDC, they are redirected to their OP (OpenID Provider), where they authenticate and are then redirected back to the application or service. OpenID is decentralized and not owned by anyone, nor should it be. Today, anyone can choose to use an OpenID or become an OpenID Provider for free without having to register or be approved by any organization. OpenID Connect adds an identity layer on top of OAuth 2.0. When configured as an OAuth client / resource server, Access Policy Manager (APM) can interact with an OpenID Connect provider to get this data: UserInfo requests APM can make UserInfo requests to an endpoint that is specified for that purpose on an OAuth provider. APM supports UserInfo requests from the OAuth Scope and OAuth Client agents in an access policy or a per-request policy subroutine. ID Token As defined in the OpenID Connect core 1.0 spec, an ID Token contains claims by an authorization server about the authenticated user when using a client. APM obtains an ID Token from an OAuth provider when OpenID Connect is enabled in the OAuth Client agent in an access policy or a per-request policy. (The OAuth provider must support OpenID Connect.) The OAuth 2.0 spec has four important roles: OAuth role Description Resource Owner Can grant access to a protected resource. A resource owner can be an end-user (person) or another entity. Resource Server Hosts protected resources, and can accept and respond to requests for protected resources using access tokens. Client Makes requests for protected resources on behalf of, and with authorization from, the resource owner. The client is an application. Authorization Server Issues access tokens to the client after successfully authenticating the resource owner and obtaining authorization. APM in OAuth resource server and client roles When Access Policy Manager ® (APM ® ) acts as an OAuth resource server, users can log on using external OAuth accounts to gain access to the resources that APM protects. External OAuth accounts can be social accounts, such as Facebook and Google, or enterprise accounts, such as F5 (APM) and Ping Identity (PingFederate). In this configuration, APM becomes a client application to an external OAuth authorization server, such as F5, on another BIG-IP ® system, or Google. APM in the OAuth authorization server role When Access Policy Manager ® (APM ® ) acts as an OAuth authorization server, APM can grant authorization codes, access tokens, and refresh tokens, and APM can perform token introspection. A great series was created by the APM guru Matt_Dierick https://www.youtube.com/watch?v=vpYfm_YCBRA https://www.youtube.com/watch?v=JuVLwbffQ8s https://www.youtube.com/watch?v=ABt3UD5q7f4 More Federated labs can be access through Lab docs, https://clouddocs.f5.com/training/community/iam/html/archived/archived.html Lab walk through Access Guided Configuration support Here's the support matrix for the templates using OAuth. Use case/Component Version Compatible BIG-IP versions OAuth Authorization Server 4.3.0 14.1.x, 15.0.x, 15.1.x, 16.0.x, 16.1.x OAuth Client and Resource Server 4.4.0 14.1.x, 15.0.x, 15.1.x, 16.0.x, 16.1.x UDF Lab access: https://udf.f5.com/b/cd258f67-afbd-45c8-a2c9-9201a9f2f6c4#components Lab steps summary Create DNS Resolver. From Access Guided configuration choose proper template. Create OAuth Provider. Create OAuth Server. Create OAuth Policy (Scope). Create Virtual Server. Optional: Single Sign-On configurations. Lab configurations steps Create DNS Resolver This DNS resolver will be responsible for resolving the dns name for the Identity provider URL. Create the Forward zone to reach (if you are using DNS Proxy, specify it) - Either use the OpenID provider zone name or use (.) to forward all queries. Note, DNS Address needs to be reachable over TMM interface (not mgmt interface). Access Guided configuration template In our case we are going to deploy F5 as Client and Resoure Server Select the proper DNS Resolver Create OAuth Provider, Server and Policy Audience: Use the Client ID provided by the OpenID provider. Below we select the OAuth provider and configure the server and scope settings. Create Virtual Server Configure the required virtual server settings Assign the pool to the policy And that's it you have the configurations ready, and can start testing them, Below is the testing behavior. 1- Access URL for the virtual server. 2- User is redirected to google for user authentication. 3- User authentication pass successfully. Access OAuth dashboardApplication Programming Interface (API) Authentication types simplified
API is a critical part of most of our modern applications. In this article we will walkthrough the different authentication types, to help us in the future articles covering NGINX API Connectivity Manager authentication and NGINX Single Sign-on.Zero Trust building blocks - Leverage Microsoft Intune endpoint Compliance with F5 BIG-IP APM Access
Use case summary Conclusion Additional resources Use case summary Let's walk through a real life scenario, we have company A that's building its Zero Trust strategy and of course it will be great to make use of existing solutions to reach our target. Microsoft Intune introduces a great source of intelligence and compliance enforcement for endpoints, combined with F5 BIG-IP Access Policy Manager (APM) integrated with AzureAD this extends the enforcement to the endpoints accessing Company A resources whether it's a SAAS or locally hosted. Below is the flow of some use cases that leverage how F5 BIG-IP APM and Microsoft Intune pave the way to achieve Zero Trust strategy. We've an endpoint Managed by Microsoft Intune. Microsoft Intune contains device compliance policy to determine the conditions at which the machine to be considered compliant and the configuration profile determine the configurations for specific applications in our case (F5 Access VPN). We have the following use cases, User tries to access web application through F5 BIG-IP APM, BIG-IP is already integrated with Microsoft Intune and Azure AD. F5 BIG-IP APM acts as SP, that directs user request to AzureAD for authentication and compliance check. If the user successfully authenticate and pass compliance policy, user will be redirected back to the application with SAML assertion response otherwise the user will be denied to acces. A demo was created by our awesome Access guru Matt_Dierick User tries to use SSL VPN to access corporate resources, User click on F5 Access VPN connection pushed to the endpoint via configuration profile at Microsoft Intune. User selects the proper authentication method (Username&Password, Smart Card or Certificate based Authentication). Once user successfully authenticate and pass compliance check, a temporary certificate is pushed to the machine. The temporary certificate is used to authenticate with F5 BIG-IP APM and then the user is granted access to SSL VPN connection. A demo was created for this use case as well by our awesome Access guru Matt_Dierick , as Microsoft Intune portal got updated, we may now perform the endpoint management related tasks through endpoint.microsoft.com portal instead of portal.azure.com, make sure to follow Microsoft documentations for any new updates. Conclusion In conclusion to the highlighted use cases, we can see that we can make use of existing solutions and extend their capabilities with the ease of integration to acheive our organization Zero Trust strategy. F5 BIG-IP in general allows the organization to decouple client side connection from server side, which simplifies further services integration to boost organization security posture. F5 BIG-IP APM allows us to integrate with different parties to extend their capabilties whether they endpoint compliance, risk factor or IDaaS to use such insights for securing application or network access. In addition to corporate related secure access, if we have customers accessing applications and need integration with Google or other Open ID Connect (OIDC) provider, you can make use of F5 BIG-IP APM OIDC integration to that 3rd party for customers' access. Additional resources Configuring Access Policy Manager for MDM applications BIG-IP Access Policy Manager: Third-Party Integration OAuth and OpenID Connect - Made easy with Access Guided Configurations templatesMulti-Stores Citrix environment BIG-IP APM
Introduction In this article we are going to discuss a use case, where we have multiple stores URIs hosted at the same Citrix StoreFront. Following Citrix deployment guide , we end up with the below policy configurations, The created Form Based Single Sign-On look like the below, Note, Make sure to validate the strart URI and form action if any customization done at store front side. Additional configurations In order to adjust the configurations to match our multi-store setup, we will follow the below, As a start we will need to replicate the SSO settings to match the number of hosted stores, below example for additional two stores (StoreB, StoreC) StoreB StoreC Then we create an iRule similar to the below and attach it to XML HTTPS virtual server created by the iapp. when ACCESS_ACL_ALLOWED { switch -glob -- [string tolower [HTTP::uri]] { /citrix/storea/explicitauth/login* { WEBSSO::select Citrix_storea_sso_form_based } /citrix/storeb/explicitauth/login* { WEBSSO::select Citrix_storeb_sso_form_based } /citrix/storec/explicitauth/login* { WEBSSO::select Citrix_storec_sso_form_based } } } At the end, we remove the SSO settings under the access policy to allow our iRule to control the SSO selection. References Citrix XenApp or XenDesktop deployment guideEnhanced Modern Applications and MicroServices SSO with NGINX
Use case intro Lab setup UDF lab Link NGINX Plus configurations Auth0 Configurations Additional learning links Use case intro NGINX Plus adds Single Sign-On Access feature on top of NGINX well-known flexibility of deployment whether containerized micro application, as a caching node, reverse proxy infront of multiple applications or other types of implementations. In this article we will go through a scenario where a user is trying to access application via NGINX Plus reverse proxy with Single Sign-On feature. Testing flow, User access the application URL (http://nginxsso-app.f5-local.demo/). NGINX Plus redirects user to Auth0 for authentication. User to provide credentials to Auth0. Auth0 verifies the credentials and redirect the browser back to NGINX Plus instance. NGINX Plus validates the received code exchange flow and pass the traffic to the application. Lab setup UDF lab Link https://udf.f5.com/b/e5c321ce-3b7b-4d9b-a032-06236a3d19a6#documentation NGINX Plus configurations We will start with installing NGINX Plus, How to install NGINX Plus ? Then enable Single Sign-On module and download OpenID Connector to automate the creation of OpenID configurations via the below commands, #For Ubuntu sudo apt install nginx-plus-module-njs jq #For Centos sudo yum install nginx-plus-module-njs jq #Then update file /etc/nginx/nginx.conf and add the below line load_module modules/ngx_http_js_module.so; #Then install OpenID connector git clone https://github.com/nginxinc/nginx-openid-connect cd nginx-openid-connect Once the above steps are done, we have our NGINX Plus ready. Auth0 Configurations This can be found also through NGINX documentation via SSO Auth0 Note, Follow the NGINX guide till step 4 for Application creation. Once you have the application ready at Auth0, head to Quick Start tab In the Quick Start tab, you will be presented with the configuration lines to configure NGINX Plus for this specific application. # Checkout nginx-openid-connect template repository git clone https://github.com/nginxinc/nginx-openid-connect #Add Auth0 configurations ./configure.sh --auth_jwt_key request \ --client_id ############### \ --pkce_enable \ https://#########.eu.auth0.com/.well-known/openid-configuration #Add tenant's logout url to openid_connect_configuration.conf map $host $oidc_logout_redirect { default "https://dev-i8eatgnr2ik7hr68.eu.auth0.com/v2/logout"; } #Add Accept-Encoding type for the Token and JWKS Endpoints # openid_connect.server_conf location = /_jwks_uri { internal; ... proxy_set_header Content-Length ""; proxy_set_header Accept-Encoding "gzip"; # this is required ... } location = /_token { internal; ... proxy_set_header Content-Type "application/x-www-form-urlencoded"; proxy_set_header Accept-Encoding "gzip"; # this is required ... } #Copy OpenID Connect config files to NGINX Server sudo cp openid_connect.js \ frontend.conf \ openid_connect_configuration.conf \ openid_connect.server_conf /etc/nginx/conf.d #Passing headers to upstream servers #Edit /etc/nginx/conf.d/frontend.conf and add additional headers from id_token to the #upstream target # auth_jwt_claim_set $claim_name https://namespace/key; server { include conf.d/openid_connect.server_conf; # Authorization code flow and Relying Party processing error_log /var/log/nginx/error.log debug; # Reduce severity level as required listen 8010; # Use SSL/TLS in production location / { # This site is protected with OpenID Connect auth_jwt "" token=$session_jwt; error_page 401 = @do_oidc_flow; #auth_jwt_key_file $oidc_jwt_keyfile; # Enable when using filename auth_jwt_key_request /_jwks_uri; # Enable when using URL # Successfully authenticated users are proxied to the backend, # with 'sub' claim passed as HTTP header proxy_set_header username $jwt_claim_sub; proxy_set_header x-email $jwt_claim_email; #proxy_set_header x-custom $claim_name; # namespaced claim proxy_pass http://my_backend; # The backend site/app access_log /var/log/nginx/access.log main_jwt; } } Now, we have both our application and NGINX Plus ready for testing. Additional learning links In this section, I'm listing some of the useful learning videos that can help with additional features to the setup. Leveraging Kubernetes for Authentication and Authorization How NGINX code is constructred ? Open ID Manual approach (not using Github repo mentioned above) and deep dive in OAuth with NGINX Plus.
Leverage F5 BIG-IP APM and Azure AD Conditional Access Easy button
Integrating F5 BIG-IP APM’s Identity Aware Proxy (IAP) with Azure AD Conditional Access enables fine-grained, adaptable, zero trust access to any application, regardless of location and authentication method, with continuous monitoring and verification.
NGINX Management Suite API Connectivity Manager - Modern API driven Applications
Introduction API based applications benefits NGINX Management Suite API Connectivity Manager capabilities API Connectivity Manager use case API Connectivity Manager use case overview API Connectivity Manager traffic flows API Connectivity Manager lab & implementation References Introduction API based applications benefits Before we dive into our API gateway use case, we will go one step back and check why the move to API driven applications, below are some of the benefits for this move: Loose coupling: API-based applications can be built and maintained independently, allowing for faster development and deployment cycles. Reusability: APIs can be reused across multiple applications, reducing the need to duplicate code and effort. Scalability: API-based architecture allows for easier scaling of individual services, rather than having to scale the entire application. Flexibility: APIs allow for different client applications to consume the same services, such as web, mobile, and IoT devices. Interoperability: APIs facilitate communication between different systems and platforms, enabling integration with third-party services and data sources. Microservices: API-based architecture allows developers to build small, modular services that can be developed, deployed, and scaled independently. NGINX Management Suite API Connectivity Manager capabilities NGINX Management Suite API Connectivity Manager adds to the capabilities of the API driven applications a secure approach to authenticate, access and developing those API based applications. API Connectivity Manager is used to connect, secure, and govern our APIs. In addition, API Connectivity Manager lets us separate infrastructure lifecycle management from the API lifecycle, giving the IT/Ops teams and application developers the ability to work independently. API Connectivity Manager provides the following features: Create and manage isolated Workspaces for business units, development teams, and so on, so each team can develop and deploy at its own pace without affecting other teams. Create and manage API infrastructure in isolated workspaces. Enforce uniform security policies across all workspaces by applying global policies. Create Developer Portals that align with your brand, with custom color themes, logos, and favicons. Onboard your APIs to an API Gateway cluster and publish your API documentation to the Dev Portal. Let teams apply policies to their API proxies to provide custom quality of service for individual applications. Onboard API documentation by uploading an OpenAPI spec. Publish your API docs to a Dev Portal while keeping your API’s backend service private. Let users issue API keys or basic authentication credentials for access to your API. Send API calls by using the Developer Portal’s API Reference documentation. API Connectivity Manager use case API Connectivity Manager use case overview In our case we will have three teams, Infrastructure team, this one will be responsible for setting up the infrastructure, domains and access policies. API team, this one will be responsible for setting up the API documentation, QoS and gateway for both production and developer portals. Application team, this one will be responsible for learning the APIs through the developer portal and use the APIs through the production portal. Authentication in our case is done via two methods, API Key authentication for API version 1. OAuth2 introspection for API version 2. Note, More Authentication methods can be used (JSON Web Token Assertion) included in the following tutorial. API authentication more detailed discussion can be found here Application Programming Interface (API) Authentication types simplified Additional features like API rate limiting can be applied as well, here's a toturial to enable that feature. API Connectivity Manager traffic flows In our use case will have three flows, Management flow, illustrated below. Metrics and events collection flow, illustrated below Data flow illustrated below NGINX tutorial on how to streamline API operations with API Connectivity Manager, API Connectivity Manager lab & implementation ِThe steps we are going to follow with some useful tutorial videos are highlighted below, Setup backend API application (This step has been already done for you in the lab). Setup API Connectivity Manager infrastructure and policies. Enable API Key Authentication via the following Youtube toturial Enable API Key Authentication with API Connectivity Manager. Publish APIs and Documentation through API Connectivity Manager. Test APIs through API Developer Portal The detailed lab guide and the implementation videos Cloud labs detailed guide https://clouddocs.f5.com/training/community/nginx/html/class10/class10.html UDF lab can be found here as well https://udf.f5.com/b/ed5ffb71-bcce-47ec-9d9f-307441e4c12c#documentation Below a recorded Lab walkthrough by our awesome guru Matt_Dierick References API Connectivity Manager NGINX Management Suite NGINX Docs API Connectivity Manager UDF Lab
F5 BIG-IP Access Policy Manager (APM) - Idp integration - Cisco vManage
Introduction Lab setup F5 BIG-IP APM configurations User testing Notes Introduction Cisco vManage allows administrators to configure Single Sign-on through Idp (Identity Provider) for users (administrators) authentication. Integrating with F5 BIG-IP APM as Idp, we are able to use a wide range of authentication methods and Multi-Factor Authenticaiton techniques to enhance admins secure access. Below are the main parts: 1- Identity Provider (Idp): In our case, F5 acts as Idp that integrate with different authentication services with MFA if required. 2- Service Provider (SP): In our case, Cisco vManage. 3- Users: Whether admins, guests or operator level users, they are the one initiating the access and providing the credentials. Lab setup Below is the lab setup used in our test, Cisco vManage acting as the service provider, with the below notes, Organization name is configured under Administrator > Settings. Idp enabled and download the SAML service provider metadata. F5 BIG-IP APM acting as Idp and as a simple test we are using localdb on APM, but in production environment it's recommended to use other options like Active Directory (AD). Configure Idp settings. Import Cisco vManage metadata to create SP connector. Create SAML resource that will be used in the policy. Create Virtual Server with the access policy related to SAML. Note, It's doable to add MFA and different authentication schemes. F5 BIG-IP APM configurations At F5 BIG-IP APM side, we need to configure the below elements, Configuer Access Policy and assign it to virtual server. Logon page, Authentication. Variable assign to fetch user group membership to send it over to vManage based on the user name. Configure Idp elements: Local Idp service (Access > Federation > SAML Identity Provider > Local Idp services) Idp identity ID, this reflects the virtual server used for Idp. Assertion settings Attributes need to be sent within the SAML assertions, note here we added the Groups attribute that reflects the adminitrator privilege level. Security settings define the certificate and key used for SAML signing. Now, we need to import the Service Provider Metadata (Federation > SAML Identity Provider > External SP Connectors) Click on the arrow at create word and select Import from Metadata Select the metadata file you downloaded from vManage administrator page Type a service provider name (any name). In the sigining certificate select None. After the file is successfully imported, we need to bind this SP connector the the Idp service we created. From (Federation > SAML Identity Provider > Local Idp services) select the Idp service we created then click on bind then selct the SP Connector we created in the previous step. One final step to finalize the SAML configuration elements, Configure the SAML resource that will be used in the access policy (Access > Federation > SAML Resource) and click create, then select the Idp resource referencing our Idp service. Create Full webtop, Access > Webtops > Webtop list User testing User tries to login to Cisco vManage administration page. Browser is redirected to F5 APM login page, for user to provide the credentials. F5 APM then validates the credentials with the configured authentication service. F5 redirect the browser back with the SAML assertion to Cisco vManage and user is logged in successfully. Notes Some notes for modification might need to be done. Make sure to send the SAML attribute Groups as without it, vManage automatically assign the user as basic group. Based on your authentication service, the variable where the Group name is obtained might be different. When you try to upload the metadata to F5 SP connector, it will give an xml signed error, so you need to remove the part in the xml between the tags (<ds:Signature ….. </ds:Signature>) , then upload the metadata and choose signed certificate as none. The metadata will automatically create the .crt / .key files.
