-
Getting Started with Citrix ADC
-
Deploy a Citrix ADC VPX instance
-
Apply Citrix ADC VPX configurations at the first boot of the Citrix ADC appliance in cloud
-
Install a Citrix ADC VPX instance on Microsoft Hyper-V servers
-
Install a Citrix ADC VPX instance on Linux-KVM platform
-
Prerequisites for Installing Citrix ADC VPX Virtual Appliances on Linux-KVM Platform
-
Provisioning the Citrix ADC Virtual Appliance by using OpenStack
-
Provisioning the Citrix ADC Virtual Appliance by using the Virtual Machine Manager
-
Configuring Citrix ADC Virtual Appliances to Use SR-IOV Network Interface
-
Configuring Citrix ADC Virtual Appliances to use PCI Passthrough Network Interface
-
Provisioning the Citrix ADC Virtual Appliance by using the virsh Program
-
Provisioning the Citrix ADC Virtual Appliance with SR-IOV, on OpenStack
-
Configuring a Citrix ADC VPX Instance on KVM to Use OVS DPDK-Based Host Interfaces
-
-
Deploy a Citrix ADC VPX instance on AWS
-
Deploy a VPX high-availability pair with elastic IP addresses across different AWS zones
-
Deploy a VPX high-availability pair with private IP addresses across different AWS zones
-
Configure a Citrix ADC VPX instance to use SR-IOV network interface
-
Configure a Citrix ADC VPX instance to use Enhanced Networking with AWS ENA
-
Deploy a Citrix ADC VPX instance on Microsoft Azure
-
Network architecture for Citrix ADC VPX instances on Microsoft Azure
-
Configure multiple IP addresses for a Citrix ADC VPX standalone instance
-
Configure a high-availability setup with multiple IP addresses and NICs
-
Configure a high-availability setup with multiple IP addresses and NICs by using PowerShell commands
-
Configure a Citrix ADC VPX instance to use Azure accelerated networking
-
Configure HA-INC nodes by using the Citrix high availability template with Azure ILB
-
Configure address pools (IIP) for a Citrix Gateway appliance
-
Upgrade and downgrade a Citrix ADC appliance
-
Solutions for Telecom Service Providers
-
Load Balance Control-Plane Traffic that is based on Diameter, SIP, and SMPP Protocols
-
Provide Subscriber Load Distribution Using GSLB Across Core-Networks of a Telecom Service Provider
-
Authentication, authorization, and auditing application traffic
-
Basic components of authentication, authorization, and auditing configuration
-
On-premises Citrix Gateway as an identity provider to Citrix Cloud
-
Authentication, authorization, and auditing configuration for commonly used protocols
-
Troubleshoot authentication and authorization related issues
-
-
-
-
-
-
Persistence and persistent connections
-
Advanced load balancing settings
-
Gradually stepping up the load on a new service with virtual server–level slow start
-
Protect applications on protected servers against traffic surges
-
Retrieve location details from user IP address using geolocation database
-
Use source IP address of the client when connecting to the server
-
Use client source IP address for backend communication in a v4-v6 load balancing configuration
-
Set a limit on number of requests per connection to the server
-
Configure automatic state transition based on percentage health of bound services
-
-
Use case 2: Configure rule based persistence based on a name-value pair in a TCP byte stream
-
Use case 3: Configure load balancing in direct server return mode
-
Use case 6: Configure load balancing in DSR mode for IPv6 networks by using the TOS field
-
Use case 7: Configure load balancing in DSR mode by using IP Over IP
-
Use case 10: Load balancing of intrusion detection system servers
-
Use case 11: Isolating network traffic using listen policies
-
Use case 14: ShareFile wizard for load balancing Citrix ShareFile
-
-
-
-
Authentication and authorization for System Users
-
-
Configuring a CloudBridge Connector Tunnel between two Datacenters
-
Configuring CloudBridge Connector between Datacenter and AWS Cloud
-
Configuring a CloudBridge Connector Tunnel Between a Datacenter and Azure Cloud
-
Configuring CloudBridge Connector Tunnel between Datacenter and SoftLayer Enterprise Cloud
-
Configuring a CloudBridge Connector Tunnel Between a Citrix ADC Appliance and Cisco IOS Device
-
CloudBridge Connector Tunnel Diagnostics and Troubleshooting
-
-
Synchronizing Configuration Files in a High Availability Setup
-
Restricting High-Availability Synchronization Traffic to a VLAN
-
Understanding the High Availability Health Check Computation
-
Managing High Availability Heartbeat Messages on a Citrix ADC Appliance
-
Remove and Replace a Citrix ADC in a High Availability Setup
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已动态机器翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
This content has been machine translated dynamically.
This content has been machine translated dynamically.
This content has been machine translated dynamically.
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.
Este artigo foi traduzido automaticamente.
这篇文章已经过机器翻译.放弃
Translation failed!
nFactor concepts, entities, and terminology
This topic captures some of the major entities involved in nFactor authentication and their significance.
Login schema
nFactor decouples the ‘view’, the user interface, with the ‘model’ that is the runtime handling. nFactor’s view is defined by login schema’. Login schema is an entity that defines what user sees and specifies how to extract the data from user.
For defining view, login schema points to a file on disk that defines the logon form. This file should be according to the specification of “Citrix Common Forms Protocol.” This file is essentially an XML definition of the logon form.
In addition to the XML file, login schema contains advanced policy expressions to glean user name and password from the user’s login request. These expressions are optional, and can be omitted if user name and password from user arrive with expected form variable names.
Login schema also defines, whether current set of credentials should be used as default SingleSignOn credentials.
Policy label
A policy label is a collection of policies. It is a construct not alien to Citrix ADC’s policy infrastructure. Policy label defines an authentication factor. That is, it contains all the policies necessary to determine whether credentials from user are satisfied. All the policies in a policy label can be assumed as homogenous. Policy label for authentication cannot take policies of different type, say rewrite. To put in a different way, all the policies in a policy label validate same password/credential from user, mostly. The result of policies in a policyLabel follows logical OR condition. Hence, if the authentication specified by first policy succeeds, other policies following it are skipped.
Policy label can be created by executing the following CLI command:
add authentication policy label mylabel –loginSchema <>
A policy label takes login schema as the property. Login schema defines the view for that policy label. If login schema is not specified, an implicit login schema, LSCHEMA_INT, is associated with that policy label. Login schema decides whether a policy label becomes a passthrough or not.
Virtual server label
In Citrix ADC’s advanced policy infrastructure, a virtual server is also an implicit policy label. That’s because virtual server can also be bound with more than one policy. However, a virtual server is special because it is the entry point for client traffic and can take policies of a different type. Each of the policies it put under its own label within the virtual server. Hence, virtual server is a conglomeration of labels.
Next factor
Whenever a policy is bound to a virtual server or a policy label, it can be specified with next factor. Next factor determines what should be done if a given authentication succeeds. If there is no next factor, that concludes authentication process for that user.
Each policy bound to a virtual server or policy label can have a different next factor. This allows for ultimate flexibility where in every policy’s success can define a new path for user’s authentication. Administrator can take advantage of this fact and craft clever fallback factors for users who do not meet certain policies.
No-Auth policy
nFactor introduces a special kind of built-in policy called NO_AUTHN. NO_AUTHN policy always returns success as authentication result. No-auth policy can be created by executing the following CLI command:
add authentication policy noauthpolicy –rule <> -action NO_AUTHN
As per the command, no-authentication policy takes a rule that can be any advanced policy expression. Authentication result is always success from NO_AUTHN.
A no-auth policy in itself does not seem to add value. However, when used along with passthrough policy labels, it offers great flexibility to make logical decisions to drive user authentication flow. NO_AUTHN policy and passthrough factors offer a new dimension to nFactor’s flexibility.
Note: Check the examples that depict the usage of no-auth and passthrough in subsequent sections.`
Passthrough factor/label
Once the user has passed the authentication at virtual server (for first factor), subsequent authentications happen at policy labels or user defined (secondary) factors. Every policy label/factor is associated with a login schema entity to display view for that factor. This allows for customizing views based on the path user would have taken to arrive at a given factor.
There are specialized kinds of policy labels which do not point explicitly to a login schema. Specialized policy labels point to a login schema that does not actually point to the XML file for the view. These policy labels/factors are called ‘passthrough’ factors.
Passthrough factors can be created by executing the following CLI commands:
Example 1:
add authentication policylabel example1
Example 2:
add loginschema passthrough_schema –authenticationSchema noschema
add authentication policylabel example2 –loginschema passthrough_schema
Passthrough factor implies that authentication, authorization, and auditing subsystem should not go back to user to get credential set for that factor. Instead, it is a hint for authentication, authorization, and auditing to continue with already obtained credentials. This is useful in cases where user intervention is not desired. For example,
-
When user is presented two password fields. After the first factor, second factor does not need user intervention
-
When authentication of a type (say certificate) is done, and administrator needs to extract groups for that user.
Passthrough factor can be used with NO_AUTH policy to make conditional jumps.
nFactor authentication flow
Authentication always begins at virtual server in nFactor. Virtual server defines the first factor for the user. The first form that the user sees is served by the virtual server. The logon form that user sees can be customized at virtual server using login schema policies. If there are no login schema policies, a single user name and password field are displayed to the user.
If more than one password fields must be displayed to the user on customized form, login schema policies must be used. They allow for displaying different forms based on the configured rules (such as intranet user versus external user, service provider A versus service provider B).
Once user credentials are posted, authentication begins at authentication virtual server, the first factor. Because authentication virtual server can be configured with multiple policies, each of them is evaluated in a sequence. At any given point, if an authentication policy succeeds, the next factor specified against it is taken. If there is no next factor, the authentication process ends. If next factor exists, it is checked if that factor is a passthrough factor or a regular factor. If that is passthrough, authentication policies on that factor are evaluated without user intervention. Otherwise, login schema associated with that factor is displayed to the user.
Example of using passthrough factor and no-auth policies to make logical decisions
Administrator would like to decide nextFactor based on groups.
-
Add authentication policylabel group check
-
Add authentication policy admin group –rule http.req.user.is_member_of(“Administrators”) –action NO_AUTHN
-
Add authentication policy nonadmins –rule true –action NO_AUTHN
-
Bind authentication policy label group check –policy admingroup –pri 1 –nextFactor factor-for-admin
-
Bind authentication policy label groupcheck –policy nonadmins –pri 10 –nextfactor factor-for-others
-
Add authentication policy first_factor_policy –rule <> -action <>
-
Bind authentication vserver <> -policy first_factor_policy –priority 10 –nextFactor groupcheck
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select Do Not Agree to exit.