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 dashboard
