Advanced Clientless SSL VPN Configuration

(1)

Advanced Clientless SSL VPN Configuration

• Microsoft Kerberos Constrained Delegation Solution, page 1 • How KCD Works, page 2

• SSO Using SAML 2.0, page 7

• Configure Application Profile Customization Framework, page 13 • Encoding, page 17

• Use Email over Clientless SSL VPN, page 19

Microsoft Kerberos Constrained Delegation Solution

Many organizations want to authenticate their Clientless VPN users and extend their authentication credentials seamlessly to web-based resources using authentication methods beyond what the ASA SSO feature can offer today. With the growing demand to authenticate remote access users with smart cards and One-time Passwords (OTPs), the SSO feature falls short in meeting that demand, because it forwards only conventional user credentials, such as static username and password, to clientless web-based resources when authentication is required.

For example, neither certificate- nor OTP-based authentication methods encompass a conventional username and password necessary for the ASA to seamlessly perform SSO access to web-based resources. When authenticating with a certificate, a username and password are not required for the ASA to extend to web-based resources, making it an unsupported authentication method for SSO. On the other hand, OTP does include a static username; however, the password is dynamic and will subsequently change throughout the VPN session. In general, Web-based resources are configured to accept static usernames and passwords, thus also making OTP an unsupported authentication method for SSO.

(2)

Requirements for Microsoft Kerberos

In order for the kcd-server command to function, the ASA must establish a trust relationship between the source domain (the domain where the ASA resides) and the target or resource domain (the domain where the Web services reside). The ASA, using its unique format, crosses the certification path from the source to the destination domain and acquires the necessary tickets on behalf of the remote access user to access the services.

This crossing of the certificate path is called cross-realm authentication. During each phase of cross-realm authentication, the ASA relies on the credentials at a particular domain and the trust relationship with the subsequent domain.

How KCD Works

Kerberos relies on a trusted third party to validate the digital identity of entities in a network. These entities (such as users, host machines, and services running on hosts) are called principals and must be present in the same domain. Instead of secret keys, Kerberos uses tickets to authenticate a client to a server. The ticket is derived from the secret key and consists of the client’s identity, an encrypted session key, and flags. Each ticket is issued by the key distribution center and has a set lifetime.

The Kerberos security system is a network authentication protocol used to authenticate entities (users, computers, or applications) and protect network transmissions by scrambling the data so that only the device that the information was intended for can decrypt it. You can configure KCD to provide Clientless SSL VPN users with SSO access to any Web services protected by Kerberos. Examples of such Web services or applications include Outlook Web Access (OWA), Sharepoint, and Internet Information Server (IIS). Two extensions to the Kerberos protocol were implemented: protocol transition and constrained delegation. These extensions allow the Clientless SSL VPN remote access users to access Kerberos-authenticated applications in the private network.

Protocol transition provides you with increased flexibility and security by supporting different authentication mechanisms at the user authentication level and by switching to the Kerberos protocol for security features (such as mutual authentication and constrained delegation) in subsequent application layers. Constrained delegation provides a way for domain administrators to specify and enforce application trust boundaries by limiting where application services can act on a user’s behalf. This flexibility improves application security designs by reducing the chance of compromise by an untrusted service.

For more information on constrained delegation, see RFC 1510 via the IETF website (http://www.ietf.org).

Authentication Flow with KCD

The following figure depicts the packet and process flow a user experiences directly and indirectly when accessing resources trusted for delegation via the clientless portal. This process assumes that the following tasks have been completed:

• Configured KCD on ASA

• Joined the Windows Active Directory and ensured services are trusted for delegation

(3)

• Delegated ASA as a member of the Windows Active Directory domain

Figure 1: KCD Process

A clientless user session is authenticated by the ASA using the authentication mechanism configured for the user. (In the case of smartcard credentials, ASA performs LDAP authorization with the

userPrincipalName from the digital certificate against the Windows Active Directory).

Note

1 After successful authentication, the user logs in to the ASA clientless portal page. The user accesses a Web service by entering a URL in the portal page or by clicking on the bookmark. If the Web service requires authentication, the server challenges ASA for credentials and sends a list of authentication methods supported by the server.

KCD for Clientless SSL VPN is supported for all authentication methods (RADIUS, RSA/SDI, LDAP, digital certificates, and so on). Refer to the AAA Support table athttp://www.cisco.com/en/US/docs/ security/asa/asa84/configuration/guide/access_aaa.html#wp1069492.

Note

2 Based on the HTTP headers in the challenge, ASA determines whether the server requires Kerberos authentication. (This is part of the SPNEGO mechanism.) If connecting to a backend server requires Kerberos authentication, the ASA requests a service ticket for itself on behalf of the user from the key distribution center.

Advanced Clientless SSL VPN Configuration

(4)

3 The key distribution center returns the requested tickets to the ASA. Even though these tickets are passed to the ASA, they contain the user’s authorization data.ASA requests a service ticket from the KCD for the specific service that the user wants to access.

Steps 1 to 3 comprise protocol transition. After these steps, any user who authenticates to ASA using a non-Kerberos authentication protocol is transparently authenticated to the key distribution center using Kerberos.

Note

4 ASA requests a service ticket from the key distribution center for the specific service that the user wants to access.

5 The key distribution center returns a service ticket for the specific service to the ASA.

6 ASA uses the service ticket to request access to the Web service.

7 The Web server authenticates the Kerberos service ticket and grants access to the service. The appropriate error message is displayed and requires acknowledgment if there is an authentication failure. If the Kerberos authentication fails, the expected behavior is to fall back to basic authentication.

Configure the ASA for Cross-Realm Authentication

To configure the ASA for cross-realm authentication, you must use the following commands.

Procedure

Step 1 Join the Active Directory domain. A 10.1.1.10 domain controller (which is reachable inside the interface).

ntp hostname

Example:

hostname(config)# configure terminal

#Create an alias for the Domain Controller hostname(config)# name 10.1.1.10 DC

#Configure the Name server

Step 2 Perform a lookup.

dns domain-lookup dns server-group

Example:

This example shows a domain name of private.net and a service account on the domain controller using dcuser as the username and dcuser123! as the password.

hostname(config)# ntp server DC

#Enable a DNS lookup by configuring the DNS server and Domain name hostname(config)# dns domain-lookup inside

hostname(config)# dns server-group DefaultDNS

hostname(config-dns-server-group)# name-server DC

hostname(config-dns-server-group)# domain-name private.net

(5)

#Configure the AAA server group with Server and Realm hostname(config)# aaa-server KerberosGroup protocol Kerberos

hostname(config-asa-server-group)# aaa-server KerberosGroup (inside) host DC

hostname(config-asa-server-group)# Kerberos-realm PRIVATE.NET

#Configure the Domain Join hostname(config)# webvpn

hostname(config-webvpn)# kcd-server KerberosGroup username dcuser password dcuser123!

hostname(config)#

Configure KCD

To have the ASA join a Windows Active Directory domain and return a success or failure status, perform these steps.

Procedure

Step 1 Switch to Clientless SSL VPN configuration mode.

webvpn

Step 2 Configure the KCD.

kcd-server

Step 3 Specify the domain controller name and realm. The AAA server group must be a Kerberos type.

kcd-server aaa-server-group

Example:

ASA(config)# aaa-server KG protocol kerberos

ASA(config)# aaa-server KG (inside) host DC

ASA(config-aaa-server-host)# kerberos-realm test.edu

ASA(webvpn-config)# kcd-server KG username user1 password abc123 ASA(webvpn-config)# no kcd-server

Step 4 (Optional) Remove the specified behavior for the ASA.

no kcd-server

Step 5 (Optional) Reset to the internal state.

kcd-server reset

Step 6 Check for the presence of a KCD server and start the domain join process. The Active Directory username and password are used only in EXEC mode and are not saved in the configuration.

Administrative privileges are required for initial join. A user with service-level privileges on the domain controller will not get access.

Note

kcd domain-join username <user> password <pass>

user—Does not correspond to a specific administrative user but simply a user with service-level privileges to add a device on the Windows domain controller.

(6)

pass—The password does not correspond to a specific password but simply a user with service-level password privileges to add a device on the Windows domain controller

Step 7 Verify whether the KCD server command has a valid domain join status and then initiate a domain leave.

kcd domain-leave

Show KCD Status Information

Procedure

Purpose Command or Action

show webvpn kcd

With release 9.5.2, the following command requests domain membership through ADI. At a minimum, it returns the domain join status (either joined

Step 1

or not joined) and the failure reason (unknown, server unreachable, or invalid permissions), if applicable.

Example:

ASA#show webvpn kcd

KCD-Server Name : DC

User : user1

Password : ****

KCD State : Joined

Failure Reason : Unknown

Debug KCD

The following command is used to control the output of the KCD specific debug messages, rather than to control the level at which ADI emits syslogs, as was the case prior to version 9.5.2:

debug webvpn kcd

Show Cached Kerberos Tickets

To display all Kerberos tickets cached on the ASA, enter the following command:

show aaa kerberos[username user | host ip | hostname] Example

ASA# show aaa kerberos

Default Principal Valid Starting Expires Service Principal

[email protected] 06/29/10 18:33:00 06/30/10 18:33:00

krbtgt/[email protected]

[email protected] 06/29/10 17:33:00 06/30/10 17:33:00

asa$/[email protected]

[email protected] 06/29/10 17:33:00 06/30/10 17:33:00

(7)

http/[email protected]

ASA# show aaa kerberos username kcduser

[email protected] 06/29/10 17:33:00 06/30/10 17:33:00

asa$/[email protected]

[email protected] 06/29/10 17:33:00 06/30/10 17:33:00

http/[email protected]

ASA# show aaa kerberos host owa.example.com

[email protected] 06/29/10 06/30/10 17:33:00

Clear Cached Kerberos Tickets

To clear all Kerberos ticket information on the ASA, enter the following command:

clear aaa kerberos [ username user | host ip | hostname]

• user—Used to clear the Kerberos tickets of a specific user • hostname—Used to clear the Kerberos tickets of a specific host

SSO Using SAML 2.0

About SSO and SAML 2.0

The ASA supports SAML 2.0 so that Clientless VPN end users will be able to input their credentials only one time when they switch between Clientless VPN and other SAAS applications outside of the private network. For instance, an enterprise customer has enabled PingIdentity as their SAML Identity Provider (IdP) and has accounts on Rally, Salesforce, and Dropbox which have been SAML 2.0 SSO enabled. When you configure the ASA to support SAML 2.0 SSO as a Service Provider (SP), end users are able to sign in once and have access to all these services including Clientless VPN.

The ASA is SP enabled when SAML is configured as the authentication method for a tunnel group, the default tunnel group or any other. The Clientless VPN end user initiates Single sign-on by accessing an enabled ASA or the SAML IdP. Each of these scenarios is described below.

SAML SP-initiated SSO

When the end user initiates login by accessing the ASA using Clientless VPN, sign-on behavior proceeds as follows:

1 When the Clientless VPN end user accesses or chooses a SAML enabled tunnel group, the end user will be redirected to the SAML idP for Authentication. The user will be prompted unless the user access the group-url directly, in which case the redirect is silent.

The ASA generates a SAML Authentication Request which the browser redirects to the SAML IdP.

2 The IdP challenges the end user for credential and the end user logs in. The entered credentials must satisfy the IdP authentication configuration.

(8)

3 The IdP Response is sent back to the browser and posted to the ASA's sign-in URL. The ASA verifies the response to complete the login.

SAML IdP-initiated SSL

When the user initiates login by accessing the IdP, sign-on behavior proceeds as follows:

1 An end user accesses the IdP. The IdP challenges the end user for credentials according to the IdP's authentication configuration. The end user submits credentials and logs in to the IdP.

2 In general, the end user gets a list of SAML enabled services that have been configured with the IdP. The end user chooses the ASA.

3 A SAML response is sent back to the browser, and posted to the ASA sign-in URL. The ASA verifies the response to complete the login.

Circle of Trust

The trust relationship between the ASA and the SAML Identity Provider is established through configured certificates (ASA trustpoints).

The trust relationship between the end user and SAML Identity Provider is established through the authentication configured on IdP.

SAML Timeouts

In SAML assertion, there are NotBefore and NotOnOrAfter as follows: <saml:Conditions NotBefore="2015-03-10T19:47:41Z" NotOnOrAfter="2015-03-10T20:47:41Z">

A SAML timeout configured on the ASA will override NotOnOrAfter if the sum of NotBefore and timeout is earlier than NotOnOrAfter. If NotBefore + timeout is later than NotOnOrAfter, then NotOnOrAfter will take effect.

The timeout should be very short to prevent the assertion from being re-used after the timeout. Also, ASA administrators need to ensure the clock synchronization using NTP or manually.

Guidelines and Limitations for SAML 2.0

• SAML 2.0 SSO support is a Clientless VPN feature, so it has the same limitation and allowances as Clientless VPN such as:

◦Multi-context mode and Load Balancing is not supported. ◦Active/Standy failover is supported, not Active/Active failover. ◦IPv4 and IPv6 sessions are supported.

• SAML 2.0 SSO support applies to Clientless VPN only, AnyConnect is not supported. • ASA supports SAML 2.0 Redirect-POST binding , which is supported by all SAML IdPs.

• The ASA functions as a SAMP SP only, it cannot act as an Identity Provider in gateway mode or peer mode.

• SAML 2.0 SSO does not support internal SAML IdP and SPs, only external ones outside of the private network.

(9)

• This SAML SSO SP feature is a mutual exclusion authentication method. It cannot be used with AAA and certificate together.

• Features that are based on username/password authentication, certificate authentication, and KCD are not supported. For instance, username/password pre-filling feature, form-based Auto sign-on, Macro Substitution based Auto sign-on, KCD SSO, and so on.

• DAP is not supported for SAML enabled tunnel groups.

• Existing Clientless VPN timeout settings still apply to SAML sessions.

• ASA administrators need to ensure clock synchronization between the ASA and the SAML IdP for proper handling of authentication assertions and proper timeout behavior.

• ASA administrators have the responsibility to maintain a valid signing certificate on both ASA and IdP considering the following:

◦The IdP signing certificate is mandatory when configuring an IdP on the ASA.

◦The ASA does not do a revocation check on the signing certificate received from the IdP.

• In SAML assertions, there are NotBefore and NotOnOrAfter conditions. The ASA SAML configured

timeout interacts with these conditions as follows:

◦Timeout will override NotOnOrAfter if the sum of NotBefore and timeout is earlier than NotOnOrAfter.

◦If NotBefore + timeout is later than NotOnOrAfter then NotOnOrAfter will take effect. ◦If the NotBefore attribute is absent, the ASA will deny the login request; If the NotOnOrAfter

attribute is absent and SAML timeout is not set, ASA will deny the login request.

Configure a SAML 2.0 Identity Provider (IdP)

Before You Begin

Get the Sign-in and Sign-out URLs for your SAML (IdP) provider. You can get the URLs from the provider's website, or they may provide that information in a metadata file.

Procedure

Step 1 Create a SAML identity provider in webvpn config mode and enter saml-idp sub-mode under webvpn. [no] saml idp idp-entityID

idp-entityID— The SAML IdP entityID must contain 4 to 256 characters. To remove a SAML IdP, use the no form of this command.

Step 2 Configure the IdP URLs.

url [sign-in | sign-out] value

value —This is the URL for signing into the IdP or the URL for redirecting to when signing out of the IdP. The sign-in URL is required, the sign-out URL is optional The url value must contain 4 to 500 characters.

Step 3 (Optional) Configure the Clientless VPN base URL.

(10)

base-url URL

This URL is provided to third-party IdPs to redirect end users back to the ASA.

When base-url is configured, we use it as the base URL of the AssertionConsumerService and SingleLogoutService attribute in show saml metadata.

When base-url is not configured, the URL is determined by the ASA's hostname and domain-name. For example, we use https://ssl-vpn.cisco.com when hostname is ssl-vpn and domain-name is cisco.com.

An error occurs if neither base-url nor the hostname/domain-name are configured when entering show saml

metadata.

Step 4 Configure trustpoints between the IdP and SP (ASA).

trustpoint [idp | sp] trustpoint-name

idp—Specifies the trustpoint that contains the IdP certificate for the ASA to verify SAML assertions. sp (Optional)—Specifies the trustpoint that contains the ASA (SP)'s certificate for the IdP to verify ASA's

signature or encrypted SAML assertion.

trustpoint-name—Must be a previously configured trustpoint.

Step 5 (Optional) Configure SAML timeout.

timeout assertion timeout-in-seconds

If specified, this configuration overrides NotOnOrAfter if the sum of NotBefore and timeout-in-seconds is earlier than NotOnOrAfter.

If not specified, NotBefore and NotOnOrAfter in the assertion is used to determine the validity.

Step 6 (Optional) Enable or disable (default setting) the signature in SAML request.

signature

Step 7 Use show webvpn saml idp to view the configuration.

Example

The following example configures an IdP named salesforce_idp and uses preconfigured trustpoints: ciscoasa(config)# webvpn

ciscoasa(config-webvpn)#saml idp salesforce_idp ciscoasa(config-webvpn-saml-idp)#url sign-in

https://asa-dev-ed.my.salesforce.com/idp/endpoint/HttpRedirect ciscoasa(config-webvpn-saml-idp)#url sign-out

https://asa-dev-ed.my.salesforce.com/idp/endpoint/HttpRedirect

ciscoasa(config-webvpn-saml-idp)#trustpoint idp salesforce_trustpoint ciscoasa(config-webvpn-saml-idp)#trustpoint sp asa_trustpoint

ciscoasa(config)#show webvpn saml idp saml idp salesforce_idp

url sign-in https://asa-dev-ed.my.salesforce.com/idp/endpoint/HttpRedirect url sign-out https://asa-dev-ed.my.salesforce.com/idp/endpoint/HttpRedirect trustpoint idp salesforce_trustpoint

trustpoint sp asa_trustpoint

The following web page shows an example of how to get URLs for Onelogin,

https://onelogin.zendesk.com/hc/en-us/articles/202767260-Configuring-SAML-for-Clarizen

(11)

The following web page is an example of how to use metadata to find the URLs from OneLogin. http://onlinehelp.tableau.com/current/online/en-us/saml_config_onelogin.htm

What to Do Next

Apply SAML authentication to connection profiles, as described inConfigure ASA as a SAML 2.0 Service Provider (SP), on page 11.

Configure ASA as a SAML 2.0 Service Provider (SP)

Follow this procedure to configure a particular tunnel group as a SAML SP.

Before You Begin

The IdP must have been previously configured. SeeConfigure a SAML 2.0 Identity Provider (IdP), on page 9.

Procedure

Step 1 In tunnel-group webvpn sub-mode, use the saml identify-provider command to assign an IdP. [no] saml identify-provider idp-entityID

idp-entityID—Must be one of the existing IdPs previously configured. To disable SAML SP, use the no form of this command.

Step 2 Enable SAML SP feature for the current tunnel group.

authentication saml

SAML authentication method is mutually exclusive.

Example

ciscoasa(config)# webvpn

ciscoasa(config-webvpn)# tunnel-group-list enable

ciscoasa(config)# tunnel-group cloud_idp_onelogin type remote-access ciscoasa(config)# tunnel-group cloud_idp_onelogin webvpn-attributes ciscoasa(config-tunnel-webvpn)# authentication saml

ciscoasa(config-tunnel-webvpn)# group-alias cloud_idp enable ciscoasa(config-tunnel-webvpn)# saml identity-provider https://app.onelogin.com/saml/metadata/462950

Example SAML 2.0 and Onelogin

Follow this example using your third party SAML 2.0 IdP in place of the Onelogin information and naming.

1 Set time synchronization between the IdP and the ASA(SP). ciscoasa(config)# ntp server 209.244.0.4

2 Obtain the IdP's SAML metadata from the IdP following procedures provided by your third party IdP.

(12)

3 Import the IdP's signing certificate into a trustpoint. ciscoasa(config)# crypto ca trustpoint onelogin ciscoasa(config-ca-trustpoint)# enrollment terminal ciscoasa(config-ca-trustpoint)# no ca-check

ciscoasa(config-ca-trustpoint)# crypto ca authenticate onelogin Enter the base 64 encoded CA certificate.

End with the word "quit" on a line by itself quit

INFO: Certificate has the following attributes: Fingerprint: 85de3781 07388f5b d92d9d14 1e22a549 Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted.

% Certificate successfully imported

4 Import the SP (ASA) signing PKCS12 into a trustpoint

ciscoasa(config)# crypto ca import asa_saml_sp pkcs12 password Enter the base 64 encoded pkcs12.

End with the word "quit" on a line by itself: quit

INFO: Import PKCS12 operation completed successfully

5 Add a SAML IdP:

ciscoasa(config-webvpn)# saml idp https://app.onelogin.com/saml/metadata/462950

6 Configure attributes under saml-idp sub-mode: Configure the IdP sign-in URL and sign-ou URL: ciscoasa(config-webvpn-saml-idp)# url sign-in

https://ross.onelogin.com/trust/saml2/http-post/sso/462950 ciscoasa(config-webvpn-saml-idp)# url sign-out

https://ross.onelogin.com/trust/saml2/http-redirect/slo/462950 Configure the IdP trustpoint and the SP trustpoint

ciscoasa(config-webvpn-saml-idp)# trustpoint idp onelogin ciscoasa(config-webvpn-saml-idp)# trustpoint sp asa_saml_sp

Configure the Clientless VPN base URL, SAML request signature and SAML assertion timout: ciscoasa(config-webvpn-saml-idp)# base-url https://172.23.34.222

ciscoasa(config-webvpn-saml-idp)# signature

ciscoasa(config-webvpn-saml-idp)# timeout assertion 7200

7 Configure an IdP for a tunnel group and enable SAML authentication. ciscoasa(config)# webvpn

ciscoasa(config-webvpn)# tunnel-group-list enable

ciscoasa(config)# tunnel-group cloud_idp_onelogin type remote-access ciscoasa(config)# tunnel-group cloud_idp_onelogin webvpn-attributes ciscoasa(config-tunnel-webvpn)# authentication saml

ciscoasa(config-tunnel-webvpn)# group-alias cloud_idp enable ciscoasa(config-tunnel-webvpn)# saml identity-provider https://app.onelogin.com/saml/metadata/462950

8 Show the ASA's SAML SP metadata:

You can get the ASA's SAML SP metadata from

https://172.23.34.222/saml/sp/metadata/cloud_idp_onelogin. In the URL, cloud_idp_oneloginis the tunnel group name.

9 Configure a SAML SP on your third party IdP following procedures provided by your third party IdP.

Troubleshooting SAML 2.0

Use debug webvpn samlvalue to debug SAML 2.0 behavior. The following SAML messages will be displayed depending on the value :

• 8—errors

(13)

• 16—warnings and errors

• 128 or 255—debug, warnings, and errors

Configure Application Profile Customization Framework

Clientless SSL VPN includes an Application Profile Customization Framework (APCF) option that lets the ASA handle non-standard applications and Web resources so they display correctly over a Clientless SSL VPN connection. An APCF profile contains a script that specifies when (pre, post), where (header, body, request, response), and what (data) to transform for a particular application. The script is in XML and uses sed (stream editor) syntax to transform strings/text.

You can configure and run multiple APCF profiles in parallel on an ASA. Within an APCF profile script, multiple APCF rules can apply. The ASA processes the oldest rule first, based on configuration history, the next oldest rule next.

You can store APCF profiles on the ASA flash memory, or on an HTTP, HTTPS, or TFTP server. We recommend that you configure an APCF profile only with the assistance of Cisco personnel.

Manage APCF Packets

Procedure

Step 1 Switch to Clientless SSL VPN configuration mode.

webvpn

Step 2 Identify and locate an APCF profile to load on the ASA.

apcf

Example:

This example shows how to enable an APCF profile named apcf1.xml, located in flash memory and how to enable an APCF profile named apcf2.xml, located on an HTTPS server called myserver, port 1440, with the path being /apcf.

hostname(config)# webvpn

hostname(config-webvpn)# apcf flash:/apcf/apcf1.xml

hostname(config)# webvpn

hostname(config-webvpn)# apcf https://myserver:1440/apcf/apcf2.xml

APCF Syntax

APCF profiles use XML format, and sed script syntax, with the XML tags in the following table.

(14)

Guidelines for APCF

Misuse of an APCF profile can result in reduced performance and undesired rendering of content. In most cases, Cisco Engineering supplies APCF profiles to solve specific application rendering issues.

Table 1: APCF XML Tags

Use Tag

The mandatory root element that opens any APCF XML file.

The mandatory tag that specifies the APCF implementation version. Currently the only version is 1.0.

The mandatory tag that wraps the body of the XML description.

The mandatory tag that describes this particular APCF functionality.

The mandatory tag that wraps a single or multiple APCF entities.

<apcf-entities>...</apcf-entities>

One of these tags specifies type of content or the stage at which the APCF processing should take place. <js-object>…</js-object> <html-object>…</html-object> <process-request-header>...</process-request-header> <process-response-header>...</process-response-header> <preprocess-response-body>...</preprocess-response-body> <postprocess-response-body>...</postprocess-response-body>

(15)

Use Tag

A child element of the pre/post-process tags that specifies criteria for processing such as:

• http-version (such as 1.1, 1.0, 0.9) • http-method (get, put, post, webdav) • http-scheme (“http/”, “https/”, other) • server-regexp regular expression containing

("a".."z" | "A".."Z" | "0".."9" | ".-_*[]?") • server-fnmatch (regular expression

containing ("a".."z" | "A".."Z" | "0".."9" | ".-_*[]?+()\{},"),

• user-agent-regexp • user-agent-fnmatch • request-uri-regexp • request-uri-fnmatch

• If more than one of condition tags is present, the ASA performs a logical AND for all tags.

Wraps one or more actions to perform on the content under specified conditions; you can use the following tags to define these actions (shown below): • <do> • <sed-script> • <rewrite-header> • <add-header> • <delete-header> <action> … </action>

(16)

Use Tag

Child element of the action tag used to define one of the following actions:

• <no-rewrite/>—Do not mangle the content received from the remote server.

• <no-toolbar/>—Do not insert the toolbar. • <no-gzip/>—Do not compress the content. • <force-cache/>—Preserve the original

caching instructions.

• <force-no-cache/>—Make object non-cacheable.

• <

downgrade-http-version-on-backend>—Use HTTP/1.0 when sending the request to remote server.

Child element of the action tag used to change the content of text-based objects. The Text must be a valid Sed script. The <sed-script> applies to the <conditions> tag defined before it.

<sed-script> TEXT </sed-script>

Child element of the action tag. Changes the value of the HTTP header specified in the child element <header> tag shown below.

<rewrite-header></rewrite-header>

Child element of the action tag used to add a new HTTP header specified in the child element <header> tag shown below.

<add-header></add-header>

Child element of the action tag used to delete the specified HTTP header specified by the child element <header> tag shown below.

<delete-header></delete-header>

Specifies the name HTTP header to be rewritten, added, or deleted. For example, the following tag changes the value of the HTTP header named Connection: <rewrite-header> <header>Connection</header> <value>close</value> </rewrite-header> <header></header>

Configuration Examples for APCF

<APCF>

(17)

<id>Do not compress content from example.com</id> <apcf-entities> <process-request-header> <conditions> <server-fnmatch>*.example.com</server-fnmatch> </conditions> <action> <do><no-gzip/></do> </action> </process-request-header> </apcf-entities> </application> </APCF> <APCF> <version>1.0</version> <application>

<id>Change MIME type for all .xyz objects</id> <apcf-entities> <process-response-header> <conditions> <request-uri-fnmatch>*.xyz</request-uri-fnmatch> </conditions> <action> <rewrite-header> <header>Content-Type</header> <value>text/html</value> </rewrite-header> </action> </process-response-header> </apcf-entities> </application> </APCF>

Encoding

Character encoding, also called “character coding” and “a character set,” is the pairing of raw data (such as 0s and 1s) with characters to represent the data. The language determines the character encoding method to use. Some languages use a single method, while others do not. Usually, the geographic region determines the default encoding method used by the browser, but the remote user can change it. The browser can also detect the encoding specified on the page, and render the document accordingly.

The encoding attribute lets you specify the value of the character-encoding method used on the portal page to ensure that the browser renders it properly, regardless of the region in which the user is using the browser, and regardless of any changes made to the browser.

By default, the ASA applies the “Global Encoding Type” to pages from Common Internet File System servers. The mapping of CIFS servers to their appropriate character encoding, globally with the “Global Encoding Type” attribute, and individually with the file-encoding exceptions displayed in the table, provides for the accurate handling and display of CIFS pages when the proper rendering of filenames or directory paths, as well as pages, is an issue.

View or Specify Character Encoding

With encoding, you can view or specify the character encoding for Clientless SSL VPN portal pages.

(18)

Procedure

Step 1 Global Encoding Type determines the character encoding that all Clientless SSL VPN portal pages inherit except for those from the CIFS servers listed in the table. You can type the string or choose one of the options from the drop-down list, which contains the most common values, as follows:

• big5 • gb2312 • ibm-850 • iso-8859-1 • shift_jis

If you are using Japanese Shift_jis Character encoding, click Do Not Specify in the Font Family area of the associated Select Page Font pane to remove the font family.

Note

• unicode • windows-1252 • none

If you click none or specify a value that the browser on the Clientless SSL VPN session does not support, it uses its own default encoding.

Note

You can type a string consisting of up to 40 characters, and equal to one of the valid character sets identified in http://www.iana.org/assignments/character-sets. You can use either the name or the alias of a character set listed on that page. The string is case-insensitive. The command interpreter converts upper-case to lower-case when you save the ASA configuration.

Step 2 Enter the name or IP address of a CIFS server for which the encoding requirement differs from the “Global Encoding Type” attribute setting. The ASA retains the case you specify, although it ignores the case when matching the name to a server.

Step 3 Choose the character encoding that the CIFS server should provide for Clientless SSL VPN portal pages. You can type the string, or choose one from the drop-down list, which contains only the most common values, as follows: • big5 • gb2312 • ibm-850 • iso-8859-1 • shift_jis

If you are using Japanese Shift_jis Character encoding, click Do Not Specify in the Font Family area of the associated Select Page Font pane to remove the font family.

Note

• unicode • windows-1252 • none

(19)

If you click none or specify a value that the browser on the Clientless SSL VPN session does not support, it uses its own default encoding.

You can type a string consisting of up to 40 characters, and equal to one of the valid character sets identified in http://www.iana.org/assignments/character-sets. You can use either the name or the alias of a character set listed on that page. The string is case-insensitive. The command interpreter converts upper-case to lower-case when you save the ASA configuration.

Use Email over Clientless SSL VPN

Configure Web email: MS Outlook Web App

The ASA supports Microsoft Outlook Web App to Exchange Server 2010 and Microsoft Outlook Web Access to Exchange Server 2007, 2003, and 2000.

Procedure

Step 1 Enter the URL of the email service into the address field or click an associated bookmark in the Clientless SSL VPN session.

Step 2 When prompted, enter the email server username in the format domain\username.

Step 3 Enter the email password.

(20)