Edge Client OAuth with Azure
Hello All, I tried OAuth feature on Edge Client with Azure as IDP. It works, I receive the Access Token and connect successfully. The problem is that Policy does not parse the JWT token and just stores it as secure variable. So I have no information about the user. I can parse it with an irule, but I expected to be parsed automatically, lilke when you use an OAuth Client in VPE. Am I missing something?
OAuth SSO like SAML Inline SSO possible?
Hi Folks, I have the following challenge and I am unsure, how it can be solved. F5 APM as OAuth Authorization Server Web Application as OAuth Client + Ressource Server Szenario 1: Internal Access This works like a charme. The user go's to the Web Application, clicks on the OIDC Login Link, is redirected to the Authorization Server, etc. The classic grant flow. Szenario 2: External Access through APM Portal The customer demand is, to publish this web application through a F5 APM Webtop with single sign on. The Web Application does not support getting the JWT from the authorization header, therefore all Bearer SSO methodes are not working. The application must go through the OAuth Grant Flow transparently for the user. This looks like the SAML Inline SSO method, but that is not possible with OAuth or do I miss anything? I have two ideas, how this can be solved. It would be great, If someone knows an even simpler method. Publish the OAuth Server in the internet. Publish the Web Application through a new Virtual Server with an Access Profile attached. Add Portal Link to the Web Application. Span the access session accross both Access Profiles. Opening the Web Application from the Web Top -> works seamless with the same Access Session Clicking on the OIDC Login Link at the Web Application Redirect to the OAuth Server New Access Session begins and the user must login again -> BAD The new access session for the Authorization server is required, because: The Access Policy must be validated to trigger the OAuth Authorization VPE Agent. The Access Policy is closed automatically after OAuth Authorization. First idea: At initial login on the Webtop: Generate a secure domain cookie Set it in the browser Write a mapping table (ltm table) cookie->username At the OAuth Server: Get the cookie Lookup the username in the mapping table If found, set the OAuth username, else prompt for authentication OAuth Authorization works without user login again Second idea: At initial auth-redirect Request from the Web Application: Intercept the auth-redirect request Use a sideband connection to request the authorization code from the authorization server (skip authentication, authorization server is only available on the f5 itself) Use another sideband connection to send the authorization code via the redirect-request back to the Web Application Use the redirect-request response as the response for 1. and deliver it to the browser This are the only two ideas I have, too solve this challenge. However, is it really as complex as I think or is there a really simple method I have overseen?Request and validate OAuth / OIDC tokens with APM
BIG-IP APM is able to request and validate OAuth2.0 and OpenID Connect tokens. It can act as Client, Resource Server and Authorization Server. In this article, I cover the use cases where APM acts as Resource Server (validating the tokens) and Client (requesting the tokens). 1. The tokens : Access Token: this is the Oauth2.0 token (access_token). It is used for Authorization and has to bevalidated by the Resource server. This Resource Server will contact the Authorization server for validation (Out of Path validation - External) Access Token can be either OPAQUE or JWT ID Token: this is the OpenID Token (id_token).It is used by the client onlyin order to know you use the resource owner. For instance, when you see you name and your picture on the top right corner of an app, this comes from the ID_Token. This token is not user/validated by the Resource Server ID Token is JWT only 2. OPAQUE vs JWT tokens : JWT: Decodable Encryptable Can be validated against a preconfigured JWKS in-box or externally OPAQUE: Not decodable (opaque) Proprietary format, might be any length, and must be unique Must be validated in out-of-path HTTP request to the originating provider (the Authorization Server) 3. Token validation : OAuth Scope agentis used to validate anAccess Token either against aninternalJSON web key set (JWKS) if the Access Token isJWTvia an APM provider configuration (Azure AD uses JWT only) orexternallyvia HTTPS if the Access Token isOpaque. JWKS is faster because we don't have an extra HTTP transaction. Oauth Scope agentis used when APM is RS and the request from the client (APM or mobile app) has a authorization bearer header. Either with Opaque (External)or JWT token (Internal). With Opaque token, if the RS needs more information about the user, it needs to request anOpenID Connect UserInfoby presenting theaccess_token to the AS. The opaque scope provides with several information but it depends of the AS. For Google, an OIDC userInfo is needed to get the First and Last names. 4. Token Request : Oauth Client agentis used to request theAccess token and id_tokenwhen APM is deployed asOauth Client. To do so, 2 grant types are available (Code and password) WithAuthorization code grant, the Client agentexchangesan Authorization code for an access_token code + id_token (if OIDC used). When the Oauth Client gets the access_token (and id_token), theOauth scope agent validatesthem.
How to customise Azure AD OIDC user ID token for APM integration
Overview A Service Provider (SP) such as the F5 APM can integrate with Azure AD (AAD) as an Identity Provider (IDP) for federated authentication using OpenID Connect (OIDC). Through this process, a user visiting APM (e.g., https://myapps.acme.corp ) is immediately redirected to AAD for authentication, once authenticated, AAD returns a code to the APM via the user browser. The APM grabs that code, adds additional information, sends them together to AAD, and finally receives an ‘access_token’ and ‘id_token’. This article takes a special focus around what is included in ‘id_token’ that AAD returns, as it is used by APM, and broadly speaking by any relying party SP, for the purpose of session creation. ‘id_token’ (part of OIDC) contains user identity information and is highly customizable. The customization of ‘id_token’ is completely done within AAD. The concept is simple, but not until it is well understood in my experience; especially with the AAD having a bunch of configuration items in the mix, such as ‘Token configuration’, ‘API permissions’ and ‘Expose an API’. This article hopes to cut all the clutter and un-muddy the water so to speak, around this topic. OIDC As a refresher, the difference between oAuth and OIDC lies in that OIDC is an identity piece laying on top of oAuth. Specifically, with oAuth, ‘access_token’ alone is returned, whereas with OIDC, ‘id_token’ is returned in addition to ‘access_token’. Scope To tell AAD we are using OIDC, the APM needs to include a scope named ‘openid’ in its outbound request to the AAD. This is achieved via the following setting. Within AAD, your application must include ‘openid’, as shown below. By default, the ‘openid’ scope comes with a list of claims that will be included in ‘id_token’. However, for certain claims to be available, additional scopes are also required. For example, if you want to have ‘preferred_username’and ‘name’ claims included, ‘profile’ scope needs to be added as well, as is depicted in the following. AAD also lets you add optional claims via ‘Token configuration’ as shown below. If these optional claims need additional scopes, AAD will add those scopes in for you under ‘API permissions’. On the APM ‘OAuth Client’ configuration, make sure to add those scopes in as highlighted below. Once the APM matches scope with AAD, AAD will include all claims in ‘id_token’ it sends back to the APM. The APM is then able to consume those claims based on the use case (e.g., create a session using email) I am hoping that this short article sheds some light around your integration work around this space.
Keycloak as idp for APM
Dear devcentral, Has anyone successfully integrated keycloak as an OIDC backend for APM on F5? We are running v13.1 so this version should be able to use this feature, right? So far I have successfully setup a provider using the autodiscover OpenID URI. Created a client application on the keycloak server with the client_id and secret. Next I'm somewhat confused on how to proceed? From what I read in the docs I need to configure the custom requests for keycloak. Though I can't seem the find these. Kind regards, Joren
Authenticate user of native mobile app with OpenId Connect
Does F5 Big IP Access Manager support mobile apps authenticating over OpenId Connect with custom URI redirect_uri? Our native mobile app (iOS and Android) authenticates the user using the Authorization Code Grant flow. How it Works. Our redirect_uri (ie callback uri) is: com.mckesson.wfm.ansos2go://signin We are a software vendor in the Healthcare domain. Our customer who uses F5 Big IP says that this URI is considered invalid by F5 when configuring the OpenId Connect Service Provider. Is that true? If so, how do native mobile app developers perform OIDC authentication with F5? Thanks, Scott UPDATE: I got word from my customer that they set up a rewrite policy, so they could enter the redirect_uri as https:/com.mckesson.wfm.ansos2go://signin. Then, they strip off the https:// in the response to the initial 'authorize' call. This is NUTS! Why does F5 Big IP Access Manager require redirect_uri to be https://...? This totally breaks the OpenId Connect specification which says "The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application." https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpointRequest and validate OAuth/OIDC tokens with APM when F5 is behind a web proxy
This question concerns a deployment using OpenID Connect with Okta as the Authorization server and F5 APM as the Resource server. The F5 is running LTM 14.1 and is in non-routeable address space behind a firewall and web proxy. An F5 "provider" object was configured via Access -> Federation -> OAuth Client/Resource Server -> Provider Connections to Okta via the "Authentication URI" and other URIs in the provider object occur over the management plane. The F5 must be able to resolve the name and have a route to Okta. There is no provision in the provider object to specify that the connection traverse a web proxy. For comparison, a similar problem arises when trying to connect to an OCSP server when the F5 is behind a web proxy. A solution for the OCSP connection is outlined in the article ocsp-through-an-outbound-explicit-proxy-29026. This solution uses a "proxy VIP" to direct the traffic through a web proxy. The solution works because the OCSP call is unencrypted http. However, in the case of F5 OAuth "provider" object, the connection is encrypted HTTPS. If a "proxy VIP" is configured as in the OCSP example, there does not appear to be a way to change the HTTP "GET" to a "CONNECT" in order to perform an encrypted connection through the web proxy. Is there any other way to configure an F5 as a OAuth Resource server when it is behind a web proxy?
