Citrix ADC as an OAuth IdP
Citrix ADC can now be configured as an identity provider by using the OpenID-Connect (OIDC) protocol. OIDC protocol strengthens the identity providing capabilities of Citrix ADC. You can now access the enterprise wide-hosted application with a single sign-on as OIDC offers more security by not transferring the user password but using tokens with specific lifetime. OpenID is also designed to integrate with non-browser clients such as apps and services. Therefore, the OIDC protocol is widely adopted by many implementations.
Note
Citrix ADC must be on version 12.1 or later to work as an OAuth IdP using the OIDC protocol.
Advantages of having Citrix ADC as an OAuth IdP
- Eliminates the overhead of maintaining multiple authentication passwords as the user has a single identity across an organization.
- Provides a robust security for your password as the password is shared only with your identity provider and not with any application you access.
- Provided vast interoperability with various systems making it easier for the hosted applications to accept OpenID.
Note
Citrix ADC Advanced Edition and higher is required for the solution to work.
To configure Citrix ADC as an OAuth IdP using the GUI
-
Navigate to Configuration > Security > AAA-Application Traffic > Policies > Authentication > Advanced Policies > OAuth IdP.
-
Click Profile and click Add.
On the Create Authentication OAuth IDP Profile screen, set values for the following parameters and click Create.
-
Name – Name of the authentication profile. Must begin with a letter, number, or the underscore character (_), and must contain only letters, numbers, and the hyphen (-), period (.) pound (#), space ( ), at (@), equals (=), colon (:), and underscore characters. Cannot be changed after the profile is created.
- Client ID – Unique string that identifies SP. The authorization server infers client configuration using this ID. Maximum Length: 127.
- Client Secret – Secret string established by user and authorization server. Maximum Length: 239.
- Redirect URL – Endpoint on SP to which code/token has to be posted.
- Issuer Name – Identity of the server whose tokens are to be accepted. Maximum Length: 127.
- Audience – Target recipient for the token being sent by IdP. This might be checked by the recipient.
- Skew Time – This option specifies the allowed clock skew in number of minutes that Citrix ADC allows on an incoming token. For example, if skewTime is 10, then the token would be valid from (current time - 10) min to (current time + 10) min, that is 20 min in all. Default value: 5.
- Default Authentication Group – A group added to the session internal group list when this profile is chosen by IdP which can be used in nFactor flow. It can be used in the expression (AAA.USER.IS_MEMBER_OF(“xxx”)) for authentication policies to identify relying party related nFactor flow. Maximum Length: 63
A group added to the session for this profile to simplify policy evaluation and help in customizing policies. This is the default group that is chosen when the authentication succeeds in addition to the extracted groups. Maximum Length: 63.
-
-
Click Policies and click Add.
-
On the Create Authentication OAuth IDP Policy screen, set values for the following parameters and click Create.
- Name – The name of the authentication policy.
- Action – Name of profile created earlier.
- Log Action – Name of the message log action to use when a request matches this policy. Not a mandatory filed.
- Undefined-Result Action – Action to perform if the result of policy evaluation is undenfined(UNDEF). Not a mandatory field.
- Expression – Default syntax expression that the policy uses to respond to specific request. For example, true.
- Comments – Any comments about the policy.
Binding the OAuthIDP policy and LDAP policy to the authentication virtual server
-
Navigate to Configuration > Security > AAA-Application Traffic > Policies >Authentication > Advanced Policies > Actions > LDAP.
-
On LDAP Actions screen, click Add.
-
On the Create Authentication LDAP Server screen, set the values for the following parameters, and click Create.
- Name – The name of the LDAP action
- ServerName/ServerIP – Provide FQDN or IP of the LDAP server
- Choose appropriate values for Security Type, Port, Server Type, Time-Out
- Make sure Authentication is checked
- Base DN – Base from which to start LDAP search. For example, dc=aaa,dc=local.
-
Administrator Bind DN: User name of the bind to LDAP server. For example,
admin@aaa.local. - Administrator Password/Confirm Password: Password to bind LDAP
- Click Test Connection to test your settings.
- Server Logon Name Attribute: Choose “sAMAccountName”
- Other fields are not mandatory and hence can be configured as required.
-
Navigate to Configuration > Security > AAA-Application Traffic > Policies >Authentication > Advanced Policies > Policy.
-
On the Authentication Policies screen, click Add.
-
On the Create Authentication Policy page, set the values for the following parameters, and click Create.
- Name – Name of the LDAP Authentication Policy.
- Action Type – Choose LDAP.
- Action – Choose the LDAP action.
- Expression – Default syntax expression that the policy uses to respond to specific request. For example, true**.
OAuth feature now supports the following capabilities in the token API from the Relying Party (RP) side and from the IdP side of Citrix Gateway and Citrix ADC.
-
PKCE (Proof Key for Code Exchange) support
-
Support for client_assertion
To configure Citrix ADC as an IdP using the OIDC protocol by using the CLI
At the command prompt, type the following commands:
add authentication OAuthIDPProfile <name> [-clientID <string>][-clientSecret ][-redirectURL <URL>][-issuer <string>][-audience <string>][-skewTime <mins>] [-defaultAuthenticationGroup <string>]
add authentication OAuthIdPPolicy <name> -rule <expression> [-action <string> [-undefAction <string>] [-comment <string>][-logAction <string>]
add authentication ldapAction aaa-ldap-act -serverIP 10.0.0.10 -ldapBase "dc=aaa,dc=local"
ldapBindDn <administrator@aaa.local> -ldapBindDnPassword <password> -ldapLoginName sAMAccountName
add authentication policy aaa-ldap-adv-pol -rule true -action aaa-ldap-act
bind authentication vserver auth_vs -policy <ldap_policy_name> -priority 100 -gotoPriorityExpression NEXT
bind authentication vserver auth_vs -policy <OAuthIDPPolicyName> -priority 5 -gotoPriorityExpression END
bind vpn global –certkey <>
<!--NeedCopy-->
Note
You can bind more than one key. Public parts of certificates bound are sent in response to
jwks\_uri query (https://gw/oauth/idp/certs).Starting from Citrix ADC 13.0–85.19 release, the OAuth IdP introspective endpoint supports the property
active: trueIf the authentication virtual server is configured as an OAuth IdP, the well-known OAuth IdP discovery endpoint URL must be
https://<netscaler-oauth-idp-fqdn>/oauth/idp/.well-known/openid-configuration.Citrix ADC configured as an OAuth IdP does not display the
client_secret_post,client_secret_jwt,private_key_jwt, andclient_secret_basictoken endpoint authentication methods in the.well-known-Endpointresponse sent to the OAuth SP.
Encrypted tokens support on OIDC protocol
Citrix ADC with the OIDC mechanism now supports the sending of encrypted tokens along with signed tokens. The Citrix ADC uses JSON web encryption specifications to compute the encrypted tokens and supports only compact serialization of encrypted tokens. To encrypt an OpenID token, a Citrix ADC needs the public key of the relying party (RP). The public key is obtained dynamically by polling the relying party’s well-known configuration endpoint.
A new “relyingPartyMetadataURL” option is introduced in the “authentication OAuthIDPProfile.” profile.
To configure the relying party’s endpoint by using CLI
At the command prompt, type:
```set authentication OAuthIDPProfile
- **relyingPartyMetadataURL** - Endpoint at which Citrix ADC IdP can get details about the relying party being configured. Metadata response must include endpoints for jwks_uri for RP public keys.
- **refreshInterval** - Defines the rate at which this endpoint must be polled to update the certificates in minutes.
- **status** - Reflects the status of the polling operation. The status is complete once Citrix ADC successfully obtains the public keys.
**Example**
```
set authentication OAuthIDPProfile sample_profile -relyingPartyMetadataURL https://rp.customer.com/metadata -refreshInterval 50 -status < >
<!--NeedCopy-->
After the endpoint is configured, Citrix ADC first polls the relying party’s well-known endpoint to read configuration. Currently, Citrix ADC processes only the ‘jwks_uri’ endpoint.
- If the ‘jwks_uri’ is absent in the response, the status of the profile is not complete.
- If the ‘jwks_uri’ is present in the response, Citrix ADC polls that endpoint also to read the public keys of the relying party.
Note: Only RSAES-OAEP and AES GCM encryption type algorithms are supported for token encryption.
Custom attributes support on OpenID Connect
OpenID relying parties might require more than a user name or a user principal name (UPN) in the token to create the user profile or make authorization decisions. Most commonly, the user groups are required to apply authorization policies for the user. Sometimes, more details, such as the first or the last name are required for provisioning a user account.
Citrix ADC configured as an IdP can be used to send extra attributes in the OIDCid_token using expressions. Advanced policy expressions are used to send the custom attributes as per the requirement. The Citrix IdP evaluates the expressions corresponding to the attributes and then computes the final token.
Citrix ADC automatically applies JSONify in the output data. For example, numbers (such as SSN) or boolean values (true or false) are not surrounded by quotes. Multi-valued attributes, such as groups are placed within an array marker (“[” and “]”). The complex type attributes are not automatically computed, and you can configure the PI expression of those complex values as per your requirement.
To configure the relying party’s endpoint by using CLI
At the command prompt, type:
set oauthidpprofile <name> -attributes <AAA-custom-attribute-pattern>
<!--NeedCopy-->
The <AAA-custom-attribute-pattern> can be described as:
Attribute1=PI-Expression@@@attribute2=PI-Expression@@@
‘attribute1’,’attribute2’ are literal strings that represent the name of the attribute to be inserted in the id_token.
Note:
In the following example, the maximum value of the
q{myname=http.req.user.name@@@ssn="123456789"@@@jit="false"@@@groups=http.req.user.groups}expression can be 2000 bytes. It contains 4 custom attributes (myname, ssn, jit, groups). The maximum value of each custom attribute is 10000 bytes. For example, the groups attribute (evaluated based on the PI expressionhttp.req.user.groups) can contain upto 10000 bytes of data in the OIDCid_token.Example:
set oauthidpprofile sample_1 -attributes q"{myname=http.req.user.name@@@ssn="123456789"@@@jit="false"@@@groups=http.req.user.groups}"
- Preceding PI expression is an advanced policy expression that represents the value to be used against the attribute. The PI expression can be used to send a string literal, such as “’hardcoded string”’. The string literal is surrounded by double quotes around single quotes or double quotes around a start pattern (the start pattern is
"q()"). If the value of the attribute is not a string literal, the expression is evaluated at runtime and its value is sent in token. If the value at runtime is empty, the corresponding attribute is not added to the ID token.- As defined in the example, “false” is a literal string for the attribute “jit”. Also,
ssnhas hardcoded value for reference. Groups andmynameare PI expressions that yield strings.
Support for active-active GSLB deployments on Citrix Gateway
Citrix Gateway configured as an Identity Provider (IdP) using the OIDC protocol can support active-active GSLB deployments. The active-active GSLB deployment on Citrix Gateway IdP provides the capability to load balance an incoming user login request across multiple geographic locations.
Important
Citrix recommends you to bind CA certificates to the SSL service and enable certificate validation on the SSL service for enhanced security.
For more information on configuring a GSLB setup, see Example of a GSLB setup and configuration.