38 Integrating Webgate with the Open ID Connect Server

The Webgate is enhanced to understand OAuth/OpenID connect (OIDC) protocols. It can work with Oracle Identity Cloud services (IDCS) and Oracle Access Management (OAM) servers to enforce authentication/authorization for the configured resources.

38.1 Pre-requisites to Enable OAuth on Webgate

  • To protect an On-Prem application with OIDC provider, On-Prem application has to be registered with OpenID Connect provider i.e. IDCS or OAM and the configurations like introspect, access token expiry time, refresh token enabled/disabled, refresh token expiry time, etc. needs to be configured.

  • The registered OAuth application will require the following grants:

    • Authorization code.

    • Refresh Code grant (if required).

38.2 Configurations to Enable OAuth on Webgate

Webgate operates in either Cloud mode or On-Prem mode, depending on the configuration files present in the config directory:

  • Cloud mode

    Checks if the following configurations files are present, if yes, then webgate will interact with the OIDC providers (OAM/IDCS):
    • Cloud.config — This configuration file has information related to OIDC server. It is used to configure Webgate for using OAuth/OpenID connect.

      See cloud.config file
    • Cloud.policy - Declares the policy to be enforced by the Webgate.

      See cloud.policy file
    • CWallet- This file contains OAuth Client ID, OAuth Client Secret and Key to encrypt cookies. To establish a connection with an IDP, the Oracle Wallet must be present in the following folder,<WebgateInstanceDir>/config/cwg_wallet

      See Creation of Wallet

    Webgate checks for the above files to be present and will interact with the OIDC mentioned in the config.file and protect the resource mentioned in the cloud.policy file.

  • On-Prem mode— If the cloud configuration files are missing, then Webgate will operate in On-Prem mode. The Webgate will communicate with OAM server only through Oracle Access Protocol (OAP) for authentication/authorization and will protect the resource depending on the policy configured on OAM.

38.2.1 cloud.config file

Webgate checks the cloud.config file for information related to OpenID Connect (OIDC) server and will interact with either OAM OIDC provider or IDCS OIDC provider.

Following is the sample of cloud.config file for IDCS OIDC provider:

{
	"cloudgateConfig" : 
	{
		"bootstrap" : 
		{
			"callbackPrefix" : "http://apphost.us.oracle.com:port/oauth/callback",
			"externalIdUrl" : "https://oidchostport.com",
			"refresh_token" : false
		},
		"rest" : 
		{
			"httpsVerifyHost" : true,
			"httpsVerifyServer" : true,
			"httpsCertAuthFile" : "/u01/cabundle/cacert.pem",
        "httpsCrlFile"          : ""
			}
	}
}

Following is the sample of cloud.config file for OAM IDCS provider:

{
	"cloudgateConfig" : 
	{

		"gateName" : "oam",
		"bootstrap" : 
		{
			"callbackPrefix" : "http://apphost.us.oracle.com:port/oauth/callback",
			"externalIdUrl" : "https://oidchostport.com",
			"discovery_endpoint" : "/.well-known/oidc-configuration",			
			"refresh_token" : false
		},
		"rest" : 
		{
			"httpsVerifyHost" : true,
			"httpsVerifyServer" : true,
			"httpsCertAuthFile" : "/u01/cabundle/cacert.pem",
        "httpsCrlFile"          : ""
			}
	}
}

Note:

Download cacert file using http://curl.haxx.se/ca/cacert.pem

Table 38-1 Root configuration fields

Field Description Default Value Type Mandatory/Optional
gateName

Used to build the discovery_endpoint URL (if not mentioned specifically).

IDCS

Text

Mandatory for non-IDCS servers (like OAM).

discovery_endpoint

Used to build the URL if the default value is not specified.

"/.well-known/idcs-configuration"

 

Mandatory for non-IDCS servers (like OAM).

enabled

Enable/Disable authentication interception in Webgate.

If True, the Webgate will process the authentication for cloud resources.

If False, the Webgate will not process the authentication for cloud resources.

True

boolean

Optional

Table 38-2 Bootstrap configuration fields

Field Description Default Value Type Mandatory/Optional
externalIdUrl

Identity Provider URL.

 

Text

Mandatory

callbackPrefix

Self-Referential WebGate Callback URL. This is basically the server URL + '/oauth/callback'. The URL is sent in the request while redirecting to IDCS, this way IDCS can redirect back the user to this URL.

Example: http://server.us.oracle.com:7744/oauth/callback

Note: While registering an application in IDCS, the value for callbackPrefix must be same as the value provided in the RedirectURL field.

“”

Text

Mandatory

domain

It displays the domain name provided in OAM OIDC while configuration.

   

Mandatory for OAM OIDC server.

cookiedomain

This value is used in the domain flag for the token cookies.

Example: us.oracle.com

 

Text

Optional

refresh_token

Get refresh token from the identity server. The refesh token is used to generate new access token after an old access token expires.

False

Boolean

Optional

introspect

This setting is by default true.

If introspection is turned off, webgate will throw an error message “cwg: OIDC server returned error for token introspection” . So, it will advice the admin to either turn off the setting in cloud.configor turn on the setting in OIDC server.

True

Boolean

Optional

authz_idp_callback

The authorization endpoint for the identity provider.

 

Text

Optional

token_idp_callback

The token endpoint of the identity provider.

 

Text

Optional

logout_idp_callback

The logout endpoint of the identity provider

 

Text

Optional

introspect_idp_callback

The introspect endpoint of the identity provider for token validation.

 

Text

Optional

Table 38-3 Rest configuration fields

Field Description Default Value Type Mandatory/Optional
httpsVerifyServer

httpsVerifySerververifies server certficates.

False

Bool

Optional

httpsVerifyHost and httpsCertAuthFile

httpsVerifyHost verifies server certificate host names and httpsCertAuthFile is certificate authority PEM text file path.

Both these attributes are effective only when httpsVerifyServer is set to True.

Note: http://curl.haxx.se/ca/cacert.pem ,this file ontains all globally identified root CA’s certficates.

In Linux, Webgate loads the file and if the mentioned file path is incorrect/does not exist/trusted certficate is not present, then by default it will fallback to the underlying OS trust store to find the root ca entry.

In Windows, httpsCertAuthFile has no relevance In Linux and Windows, if OIDC server defines its own root CA, then you need to add it manually in the system store.

False

Bool

Optional

38.2.2 cloud.policy file

Webgate will protect the resource mentioned in the cloud.policy file, this file declares the policy to be enforced by the Webgate. The default mode of policy is 'local' and the 'default' policy from the local file is applied and enforced.

Following is the sample of cloud.policy file for IDCS OIDC provider:

{
  "cloudgatePolicy": {
    "webtierPolicy"        : [
      {
        "policyName"       : "default",
        "resourceFilters"  : [
          {
            "comment"   : "Test Application Unsupported Filter",
            "type"      : "text",
            "filter"    : "/test/unsupported",
            "method"    : "unsupported"            
          },
          {
            "comment"   : "Test Anonymous Filter",
            "type"      : "regex",
            "filter"    : "/test/anony.*",
            "method"    : "anonymous"
          },		  
          {
            "comment"   : "Test Application OAuth+Logout Filter",
            "type"      : "text",
            "filter"    : "/test/logout",
            "method"    : "oauth+logout",
			"oauthPostLogoutUrl" : "http://apphost.us.oracle.com:port/oauth/landing.htm"          },
          {
            "comment"   : "Test Application OAuth Filter",
            "type"      : "regex",
            "filter"    : "/cgi-bin/*",
            "method"    : "oauth",
            "authorize" : true,
			"scope"     : "leaveAppleave leaveAppopenid",
			"idcsscope"	: "leave openid",
			"headers"  : [ { "X_TEST" : "testvalue" },
						   { "UserName" : "$subject.user.name" },
						   { "PrimaryEmail" : "$subject.user.emails" },
						   { "PolicyName" : "$request.policy_name" },
						   { "PolicyResourceMatched" : "$request.policy_res" },
										 ]			
          },
          {
            "comment"   : "Test Application OAuth Filter",
            "type"      : "text",
            "filter"    : "/oauth/.*",
            "method"    : "anonymous",
          	"headers"  : [ { "X_TEST" : "testvalue" },
						  	{ "PolicyName" : "$request.policy_name" },
						   { "PolicyResourceMatched" : "$request.policy_res" },
						   {"phoneNumbers":"$subject.user.phoneNumbers"},
						   {"addresses":"$subject.user.addresses"},
						   {"idcsCreatedBy":"$subject.user.idcsCreatedBy"},
						   {"idcsLastModifiedBy":"$subject.user.idcsLastModifiedBy"}
						 ]			
          },                    
          {
            "comment"   : "Test Application Public Filter",
            "type"      : "regex",
            "filter"    : "/oauth/.*",
            "method"    : "anonymous",
			"headers"  : [ { "X_TEST" : "testvalue" },
						   { "PolicyName" : "$request.policy_name" },
						   { "PolicyResourceMatched" : "$request.policy_res" }						   						   
						 ]
          }          
        ]
      }
    ]
  }
}

Following is the sample for OAM OIDC provider:

{
  "cloudgatePolicy": {
    "webtierPolicy"        : [
      {
        "policyName"       : "default",
        "resourceFilters"  : [
          {
            "comment"   : "Test Application Unsupported Filter",
            "type"      : "text",
            "filter"    : "/test/unsupported",
            "method"    : "unsupported"            
          },
          {
            "comment"   : "Test Anonymous Filter",
            "type"      : "regex",
            "filter"    : "/test/anony.*",
            "method"    : "anonymous"
          },		  
          {
            "comment"   : "Test Application OAuth+Logout Filter",
            "type"      : "text",
            "filter"    : "/test/logout",
            "method"    : "oauth+logout",
			"oauthPostLogoutUrl" : "http://apphost.us.oracle.com:port/oauth/landing.htm"          },
          {
            "comment"   : "Test Application OAuth Filter",
            "type"      : "regex",
            "filter"    : "/cgi-bin/*",
            "method"    : "oauth",
            "authorize" : true,
			"scope"     : "leaveApp.leave leaveApp.openid",
			"aud" : "leaveApp",			
			"headers"  : [ { "X_TEST" : "testvalue" },
						   { "UserName" : "$subject.user.name" },
						   { "PrimaryEmail" : "$subject.user.emails" },
						   { "PolicyName" : "$request.policy_name" },
						   { "PolicyResourceMatched" : "$request.policy_res" },
										 ]			
          },
                           
          {
            "comment"   : "Test Application Public Filter",
            "type"      : "regex",
            "filter"    : "/oauth/.*",
            "method"    : "anonymous",
			"headers"  : [ { "X_TEST" : "testvalue" },
						   { "PolicyName" : "$request.policy_name" },
						   { "PolicyResourceMatched" : "$request.policy_res" }						   						   
						 ]
          }          
        ]
      }
    ]
  }
}

Table 38-4 Root configuration fields

Field Description Default Value Type Mandatory/Optional
disableAuthorize

Global override for the resource filter "authorize" flag.

False

boolean

Optional

webtierPolicy

Array of named "policy sections", each of which is an array of resource filters.

 

Array

Mandatory

Table 38-5 Policy section configuration fields

Field Description Default Value Type Mandatory/Optional
resourceFilters

An array of Resource Filter

 

Array

Mandatory

policyName

Name of the policy section.

“Default” is a reserved value.

It is driven via header in some modes.

Note: Names should be Linux file system-compatible and lowercase characters only.

 

Text

Mandatory

Table 38-6 Resource filters fields

Field Description Default Value Type Mandatory/Optional
comment

User-Defined Comment.

“”

Text

Optional

type

Specifies if the filter value is static string ('text') or a regex pattern ('regex').

Range of value: text or a valid regex

Example:

"/path/.*" will match the url /path/leave or /path/hr

Following are valid regex expressions:

c - Matches any literal character c. - Matches any single character ^ - Matches the beginning of the input string $ - Matches the end of the input string * - Matches zero or more occurrences of the previous character

 

Text

Mandatory

filter

Contains the path of a URL against which the resource request is matched, Resources are matched in the order in which they appear in the policy file (top-to-bottom).

Example:

"/path/app/leave""/path/.*"

Note:

If the filter does not match then /** is matched. If resource is not found then Error 500 (internal server error) is displayed.

 

Text

Mandatory

method

This specifies the authentication method that is used. See Authentication Methods section.

 

Text

Mandatory

authorize

This applies to only the OAuth Resource Server flow (method="oauth"). In this flow, the request contains an OAuth Access Token in an Authorization "Bearer" header.

If True, the request URL is compared with the “aud” claim of the provided Access Token. One of the Protocol and host pair (port and path, if specified) in ‘aud’ must match with the request URL.

If False, there will be no comparison.

True

boolean

Optional

scope

This applies only to the OAuth Browser flow.

The value is a space-delimited list of scopes configured for the application in OIDC

Example:

leaveAppleave leaveAppopenid

Here, leaveApp is the resource server name.

“”

Text

Mandatory only if the method specified is “oauth”.

idcsscope

Each value in this field will have a corresponding value in the scope field.

Example:

For scope value, leaveAppleave leaveAppopenid

the idcsscope value is "leave openid".

“”

Text

Mandatory only for IDCS.

aud

Defines the name of the resource server provided while configuring the app on OAM OIDC.

 

Text

Mandatory only for OAM OIDC server.

oauthPostLogoutUrl

This is only for 'oauth+logout'. The post-logout URL specifies a URL to which the browser is redirected after logout. 

The “filter” of an "oauth+logout" policy is used for matching.

Example:

"/my-non-existing-logout-page", means this logout URL can be given anywhere in your application. On accessing logout URL, WebGate will redirect the user to IDCS's end_session_endpoint and send PostLogoutURL in query params. IDCS would redirect back to the PostLogoutURL on a successful logout.

Note: 'Post Logout Redirect URL’ field should be mentioned in the clientapp.

“”

Text

Optional

headers

Specifies a list of Headers that webgate will inject into a request, before forwarding it to the protected server.

Not supported for the following Authentication Methods:

  • unsupported

  • oauth+logout

Follows the format: "headers"  : [ { "header-name1": "header-value1" }, ... { "header-nameN" :"header-valueN" }]

The Header value expression may be a simple literal string or an attribute identifier.

See Attributes section.

 

Array of objects

Optional

38.2.2.1 Authentication Methods

When a user accesses a resource, the authentication methods determines the authentication flow.

Example: Specify a resource method as “public” and if an unauthenticated user tries to access the same resource, the user is not questioned for authentication and the resource is directly served..

Table 38-7 Authentication Methods

Authentication Method Description
anonymous

If a valid access token cookie is present (from a previous "oauth" flow), then the Oauth flow is executed and the REMOTE_USER header is set with respect to the user.

If the access token cookie is missing/expired/invalid, then the "public" flow is executed, and the REMOTE_USER header is set to "anonymous". 

In both the flows, the headers will be set, but will not trigger authentication. 

oauth

OAuth authentication is invoked.

oauth+logout

Initiates the OAuth logout flow by redirecting to the OAuth "end_session_endpoint".

The resource specified in the "filter" usually does not exist, it is used only for matching against the URL of the request. If the resource does exist, it will not be accessed.

public

No authentication is performed

unsupported

Always returns 500 "Internal Server Error”

Used to disable access to a protected resource that is reachable.

38.2.2.2 Attributes

For every request, Webgate will attempt to replace the attribute identifier in the Header value expression.

Following are the three supported attributes:

  • Generic

  • Request- $request.xxx

  • User -$subject.user.xxx

Note:

To set the user attribute header, user must have either User Admin or Identity Domain Admin grant role in the Client App.

Example:

  • Generic

    Headers Array: "headers" : [ { "my-literal" : "a simple string" } ]

    Injected Header: http_my-literal : "a simple string"

  • User Attribute

    Headers Array: "headers" : [ { "user-name" : "$subject.user.name" } ]

    Injected Header: http_user-name : "<formatted name of the user>”

  • Request Attribute

    Headers Array: "headers" : [ { "req-policy" : "$request.policy_name" } ]

    Injected Header: http_req-policy : "<name of the policy used by Cloud Gate>”

Table 38-8 User Attributes

Attribute Name Header Expression Description of return value
name

$subject.user.name

The formatted name of the User.

emails

$subject.user.emails

The value of the primary email.

phoneNumbers

$subject.user.phoneNumbers

The value of the primary phone number.

addresses

$subject.user.addresses

The full primary mailing address, formatted for display or use with a mailing label.

idcsCreatedBy

$subject.user.idcsCreatedBy

The displayName of the User or App who created this Resource.

idcsLastModifiedBy

$subject.user.idcsLastModifiedBy

The displayName of the User or App who modified this Resource.

Table 38-9 Request Attributes

Attribute Name Header Expression Description of return value
policy_name

$request.policy_name

Name of the specific policy matched for the request. This is the value of the "policyName" property of the policy used.

policy_res

$request.policy_res

Resource URL pattern matched for the request. This will take the form: "<type>:<pattern>"

Example: "text:/my/resource" or “regex:/my/resource/.*”

38.2.3 Creation of Wallet

To establish a connection with an IDP, the Oracle Wallet must be present in the following location, <WebgateInstanceDir>/config/cwg_wallet.

The Wallet will contain the following information:

  • OAuth Client ID

  • OAuth Client Secret

  • Key to encrypt cookies

Steps to create a Wallet

  • Create a wallet using orapki utility, <OHS_MW>/oracle_common/bin/orapki

    • Command: orapki wallet create -wallet <WebgateInstanceDir>/config/cwg_wallet -auto_login

      Note:

      Wallet is copied to this location, <WebgateInstanceDir>/config/cwg_wallet. Verify if cwg_wallet directory is present, if not, create the directory and copy CWallet.sso to it.
    • Example:

      bash-4.1$ orapki wallet create -wallet cwg_wallet -auto_login

      Oracle PKI Tool : Version 12.2.1.3.0

      Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.

      Enter password:

      Enter password again:

      Operation is successfully completed.

      bash-4.1$ ls
      ewallet.p12.lck     ewallet.p12          cwallet.sso.lck       cwallet.sso

Adding information to Wallet

  • Add, Client ID & Secret of the registered application on OAM/IDCS OIDC Server in the wallet using mkstoreutility, <OHS_MW>/oracle_common/bin/mkstore

    • Command: mkstore -wrl <WebgateInstanceDir>/config/cwg_wallet -createUserCredential <mapName> <mapkeyName> <name> <Value/password/key>

      mapName="CWG"

      mapKeyName="id_secret_key"

      name=<client_id>

      password=<client_secret>

      Note:

      Use the above mentioned mapName and mapKeyName values only for storing Client ID and Secret in a wallet.
    • Example:

      bash-4.1$ mkstore -wrl cwg_wallet -createUserCredential CWG id_secret_key 123456789abcdef123456789abcdef12 aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

      Oracle Secret Store Tool : Version 12.2.1.3.0

      Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.

      Enter wallet password:

  • Create a symmetric key using openssl utility, this will be used for token encryption.

    • Command: openssl enc <encryption algo> -k "<secret/passphrase> -P -md <hashing algo>

    • Example:

      bash-4.1$ openssl enc -aes-128-gcm -k "god bless you" -P -md sha256
      salt=AAAAAAAAAAAA
      key=BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
      iv =CCCCCCCCCCCCCCCCCCCCCCCC
    • -k — represents the passphrase i.e. user provided value can be anything.

      -md — represents the hashing algo.

      enc — represents the encryption algo.

  • Add the above generated key in wallet using mkstore utility.

    • Command: ./mkstore -wrl <WebgateInstanceDir>/config/cwg_wallet -createUserCredential <mapName> <MapkeyName> <keyName> <Value/password/key>

      mapname = “CWG”

      mapKeyName="enc_key"

      keyName="enc"

      key=<symmetric key>

      Note:

      Use the above mentioned mapName, mapKeyName & name only for storing symmentric key in wallet.
    • Example:

      bash-4.1$ mkstore -wrl cwg_wallet -createUserCredential CWG enc_key enc BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

      Oracle Secret Store Tool : Version 12.2.1.3.0

      Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.

      Enter wallet password:

  • Display the wallet afer update:

    • Example:

      bash-4.1$ orapki wallet display -wallet cwg_wallet

      Oracle PKI Tool : Version 12.2.1.3.0

      Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.

      Requested Certificates:

      User Certificates:

      Oracle Secret Store entries:

      CWG@#3#@enc_key

      CWG@#3#@id_secret_key

      Trusted Certificates:

    Note:

    After creating and adding a Wallet, copy the wallet to the following directory, <WebgateInstanceDir>/config/cwg_wallet.

38.3 Understanding Authentication and Authorization flow using OIDC server

Webgate uses OAuth for applications to authenticate /authorize users against the requested resource. The authorization grant type used by WebGate is ‘Authorization Code’ grant.

38.3.1 Authorization flow when accessing a resource protected by IDCS

Following is the authorization flow when a resource owner tries to access a resource protected by IDCS:

  1. Unauthenticated resource owner requests for a resource from the client.
  2. Webgate on client intercepts the request and identifies the user is not authenticated.
  3. Webgate redirects the user to the configured IdP (IDCS) with the following query parameters:
    • Redirect URL - as configured in cloud.config file.

      Note:

      Recommended to use HTTPS instead of HTTP.
    • Requested scopes – scopes required for the resource requested.

    • State- The original requested resource.

  4. The user logs in to the IDCS server accepts the resource consent and gets an 'Authorization Code'. IDCS internally sends authorization code at the redirect_url specified in the client.
  5. Webgate intercepts the authorization code and a HTTP POST request is sent to IdP to receive an 'Access Token'. This request is performed at the back channel and is not redirected from the browser.
  6. IDCS generates an access token and returns to WebGate in the HTTP response.
  7. WebGate sets the access token in the response cookies and redirects the user back to the originally requested resource.
  8. WebGate intercepts the request when the original resource is again requested. This time it validates the access token, sets the OAM_REMOTE_USER header and lets the server serve the content.

    The following figure demonstrates the authorization flow when the user accesses a resource protected by IDCS:

    Authentication

38.3.2 Un-authorized user accessing a resource

Following is the flow when the user is authenticated but not authorized:

  1. Unauthenticated owner requests for a resource from the client.
  2. Webgate on client intercepts the request and identifies the user is not authenticated.
  3. User is redirected to sign-in page.
  4. User enters the credentials and is authenticated.
  5. IDCS checks if the user is authorized to access the requested resource/scope.
  6. IDCS identifies the user is not authorized for the requested scope and shows an error message “You are not authorized to access the app. Contact your system administrator ".

    The following figure demonstrates the above scenario:

    Un-Authorized user accessing a resource

38.3.3 User denying consent to the application

Following is the flow when user denies its consent:

  1. Unauthenticated resource owner requests for a resource from the client.
  2. Webgate on client intercepts the request and identifies the user is not authenticated.
  3. Webgate redirects the user to the configured IdP (IDCS) with the following query parameters:
    • Redirect URL- as configured in cloud.config file .

    • Requested scopes – scopes required for the resource requested.

    • State- The original requested resource.

  4. The user logs in to the IDCS server accepts the resource consent and gets an 'Authorization Code'. IDCS internally sends authorization code at the redirect_url specified in the client.
  5. Directs the user to the consent page, listing all the scopes defined.
  6. User clicks on ‘Don’t Allow’ button.
  7. Displays an error message, “500-Internal Server Error”.

    Following figure demonstrates the above-mentioned flow:

    User Deny Consent to the app

38.3.4 Logout from application protected by IDCS

Following is the scenario when user has to logout after accessing an application protected by IDCS:

  1. For login and authentication flow, follow the steps in Authorization flow when accessing a resource protected by IDCS
  2. After successful login, if the user triggers the logout url, the Access Token and ID Token, and IDCS session cookies expires.
  3. IDCS invalidates the session, it identifies the user details from the ID token sent in the query parameters and redirects the resource owner to the PostLogoutURL configured.

    Following figure illustrates the logout flow of the application from IDCS:

    Logout from application

38.3.5 Use of Refresh Tokens after expiry of Access Tokens

Refresh Tokens are credentials used to obtain Access Tokens. It is used to obtain a new access token when the current access token becomes invalid or expires.

Following is the scenario where Refresh Token is used to obtain an Access Token:

  1. Resource owner access a resource after successfully authenticating with the IDCS server. The Access Token (with an expiry of X minutes) and Refresh token is sent to the resource owner.
  2. The resource owner makes a protected resource request to the resource server by presenting the access token.
  3. The webgate checks that the resource is protected and verifies the Access Token and Refresh Token.
  4. If the Access Token is expired, the resource owner requests a new Access Token by authenticating with the authorization server and presenting the Refresh Token.
  5. The authorization server authenticates the resource owner and validates the Refresh Token, if valid, issues a new Access Token.
  6. The new encrypted access token is set in the OAMAuthnCookie_at_* .
  7. The resource owner makes a protected resource request to the resource server by presenting the new access token. The Resource server verifies the access token and if valid, lets the server serve the resource.

    Following figure illustrates obtaining Access Tokens using Refresh Tokens:

    Refresh Tokens used to obtain Access Token

38.4 Limitations

Webgate does not support the following:

  • POST data preservation is not supported in v1.

  • HTTP basic Authentication is not supported.

  • Complex regex expression is not supported

  • There is no UI to create the policies (cloud.policy).

  • Changes in any of the following configuration files requires a web server restart:

    • cwg_wallet/cwallet.sso

    • cloud.config

    • cloud.policy

  • For the WebGate protected resources, REST API requests or other non-browser requests (Example: javascript), access token should be sent in the Authorization Bearer header.

  • Only one resource filter is supported with OAuth method when OAuth cookies (OAMAuthnCookie_at/OAMAuthnCookie_rt) are enabled. To disable the cookies, use disableCookies setting:

    • disableCookies is set to ‘false’ by default, only one resource filter with OAuth method is supported (multiple resource filters with OAuth method is not supported).

    • If disableCookies is set to ‘true’, multiple resource filters with OAuth method is supported (WebGate will not set the OAuth related cookies and acts as a resource server). WebGate acts as a resource server (which only validates the access token), and the application is responsible for sending the Authorization Bearer token header with each request for Authentication/Authorization.