Sei sulla pagina 1di 22

Blue Coat Systems

Common Access Card


Solutions Guide

For SGOS 6.1.2 and later

Common Access Card Solutions Guide

2014 Blue Coat Systems, Inc. All rights reserved. BLUE COAT, PROXYSG, PACKETSHAPER, CACHEFLOW,
INTELLIGENCECENTER, CACHEOS, CACHEPULSE, CROSSBEAM, K9, DRTR, MACH5, PACKETWISE, POLICYCENTER, PROXYAV,
PROXYCLIENT, SGOS, WEBPULSE, SOLERA NETWORKS, DEEPSEE, DS APPLIANCE, SEE EVERYTHING. KNOW EVERYTHING.,
SECURITY EMPOWERS BUSINESS, BLUETOUCH, the Blue Coat shield, K9, and Solera Networks logos and other Blue Coat logos are
registered trademarks or trademarks of Blue Coat Systems, Inc. or its affiliates in the U.S. and certain other countries. This list may not be
complete, and the absence of a trademark from this list does not mean it is not a trademark of Blue Coat or that Blue Coat has stopped
using the trademark. All other trademarks mentioned in this document owned by third parties are the property of their respective
owners. This document is for informational purposes only.
BLUE COAT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
BLUE COAT PRODUCTS, TECHNICAL SERVICES, AND ANY OTHER TECHNICAL DATA REFERENCED IN THIS DOCUMENT ARE
SUBJECT TO U.S. EXPORT CONTROL AND SANCTIONS LAWS, REGULATIONS AND REQUIREMENTS, AND MAY BE SUBJECT TO
EXPORT OR IMPORT REGULATIONS IN OTHER COUNTRIES. YOU AGREE TO COMPLY STRICTLY WITH THESE LAWS,
REGULATIONS AND REQUIREMENTS, AND ACKNOWLEDGE THAT YOU HAVE THE RESPONSIBILITY TO OBTAIN ANY
LICENSES, PERMITS OR OTHER APPROVALS THAT MAY BE REQUIRED IN ORDER TO EXPORT, RE-EXPORT, TRANSFER IN
COUNTRY OR IMPORT AFTER DELIVERY TO YOU.

Americas:
Blue Coat Systems, Inc.
420 N. Mary Ave.
Sunnyvale, CA 94085

Rest of the World:


Blue Coat Systems International SARL
3a Route des Arsenaux
1700 Fribourg, Switzerland

Document Number: 231-03155


Document Revision: SGOS 6.5.x06/2014

ii

Contents
Preface

Audience .............................................................................................................................................. 1
How This Document Is Organized................................................................................................... 1
Document Conventions ..................................................................................................................... 2
Typography................................................................................................................................... 2
Notes and Warnings .................................................................................................................... 2
Related Documentation...................................................................................................................... 3
Blue Coat Knowledge Base................................................................................................................ 3
Chapter 1: Overview of Common Access Card Authentication

About Mutual SSL Authentication................................................................................................... 5


Requirements for CAC Authentication ........................................................................................... 7
Chapter 2: Configure Common Access Card Authentication
Chapter 3: Set up Authentication and Authorization

Examples of CAC Authentication Policy ...................................................................................... 12


CPL for CAC Authentication to the Management Console ................................................. 12
CPL for CAC Authentication to the Serial/SSH Console .................................................... 13
Chapter 4: Use Cases

Use Case 1: Logging in to the Management Console .................................................................. 15


Use Case 2: Logging in to the SSH Console .................................................................................. 16
Use Case 3: Logging in to the Serial Console................................................................................ 17

iii

Common Access Card Solutions Guide

iv

Preface

This Preface provides you with an overview of the intended audience for this
document, document organization, Blue Coat typographical conventions, and
related documentation.

Audience
This document is written for system administrators who want to establish a
session between a ProxySG appliance (including virtual appliances) and client
using mutual SSL authentication to support Common Access Card (CAC)
authentication.

How This Document Is Organized


This document contains the following sections:
Section

Description

Chapter 1: "Overview of
Common Access Card
Authentication" on page 5

Discusses CAC and how it is used to


authenticate users.

Chapter 2: "Configure Common


Access Card Authentication" on
page 9

Describes how to configure mutual SSL


authentication from the ProxySG appliance
Management Console.

Chapter 3: "Set up
Authentication and
Authorization" on page 11

Provides examples of CPL to enable


authentication and authorization.

Chapter 4: "Use Cases" on page


15

Provides examples of use cases.

Common Access Card Solutions Guide

Document Conventions
This document uses the following conventions.

Typography
Refer to the following typographical conventions.
Conventions

Definition

Italics

The first use of a new or Blue Coatproprietary term; also used for
emphasis.

Courier New

Command-line text.

Courier New Italic

A command-line variable that is to be


replaced by a name or value
pertaining to your network system.

Courier New Boldface

A Blue Coat AV literal to be entered as


shown.

{ }

One of the parameters enclosed within


the braces must be supplied

[ ]

An optional parameter or parameters.

You can select the parameter before or


after the pipe character.

Notes and Warnings


The following is provided for your information and to caution you against actions
that can result in data loss or personal injury:
Note: Information to which you should pay attention.

Critical information that is not related to equipment damage or


personal injury (for example, data loss).

Important:

Used only to inform you of danger of personal injury or physical


damage to equipment. An example is a warning against electrostatic discharge
(ESD) when installing equipment.

WARNING!

Related Documentation
Document

Description

Blue Coat Systems SGOS 6.x


Administration Guide

This reference guide provides comprehensive


task-based use cases that can be managed using
the appliance Management Console. It includes
information on X.509 certificate authentication
and SSL.

Blue Coat Systems Notice and Consent


Banner Webguide

This webguide provides examples of how to


enable Notice and Consent banners. CAC
authentication and Notice and Consent banners
are often deployed together, but you can deploy
them separately.

Blue Coat Systems SGOS 6.x Content


Policy Language Reference

This reference guide defines the language used


that supports a variety of authentication, Webaccess, and networking policies.

Blue Coat Systems SGOS 6.x


Command Line Interface Reference

This reference guide helps you configure and


manage your Blue Coat Systems ProxySG
appliance using CLI.

Blue Coat Systems SGOS 6.x Release


Notes

This document advises of new features, known


problems, and fixes for previously known issues.

Blue Coat Knowledge Base


The Blue Coat Knowledge Base contains information about this product that
might not be available in the documentation or Release Notes. The Knowledge
Base contains information in the following categories:

Solutions

FAQs

Alertsincluding security alerts

Technical field information

Blue Coat recommends you regularly search the Knowledge Base for latebreaking information that might not be available in product documentation or
Release Notes.
To view articles in the Knowledge Base:

1. Enter the following URL in the web browsers address or location field:
https://kb.bluecoat.com
2. Do one of the following:

To get an answer to a specific question, enter the question in the Ask a


field, and click Ask.

question

Common Access Card Solutions Guide

To filter the view to a specific set of articles, click a selection in the


horizontal navigation bar (Solutions, FAQs, and so on).
In all sections, you can browse by product, operating system, type of
deployment, or topic.

3. Follow the prompts on your screen to locate the information.

Chapter 1: Overview of Common Access Card Authentication

Chapter 1: Overview of Common Access Card Authentication

This document discusses using the Common Access Card (CAC) for
administrator authentication. The CAC is a smart card that an individual uses onpremises as an identification badge, and it contains one or more X.509 certificates
and the users private key.
The CAC performs certificate-based client authentication over an SSL connection
to the ProxySG appliance Management Console or the appliances SSH interface.
The serial interface does not support certificate-based client authentication.
Support for CAC authentication was introduced in SGOS 6.1.2.
Note: Whether TLS is supported depends on the ProxySG appliance and client
in use. For brevity, this document refers only to SSL; however, in procedures and
descriptions, SSL is interchangeable with TLS.

About Mutual SSL Authentication


In mutual SSL authentication, an SSL connection between a client and a server is
established only if the client and server validate each others identity during the
SSL handshake. The server and the client must each have their own valid
certificate and the associated private key in order to perform SSL mutual
authentication.
Certificates and private keys can be stored in multiple locations. On the client, one
such location is a CAC.
As an example, CAC authentication using mutual SSL authentication comprises
the following steps:
Figure 11

Mutual SSL authentication process using CAC

The following process describes Figure 11, "Mutual SSL authentication process
using CAC" on page 5.

Common Access Cards Solutions Guide

1. The user requests access to the Management Console.


2. (If applicable) The appliance presents a Notice and Consent banner. The user
provides consent.
3. The ProxySG appliance presents its certificate to the browser.
4. The browser validates the ProxySG appliance certificate. This includes the
following checks:

The certificate subject must match the appliances hostname.

The certificate must be issued by a CA listed in the browsers Trusted Root


Certificate store.

The browser confirms that the appliance has the certificate's private key by
challenging the appliance to sign random data. The browser validates the
signature using the appliance's certificate.

The certificate must have a valid signature and not be expired.

(If the appliance is checking for revoked certificates) The certificate must
not have been revoked.

5. If appliance authentication succeeds, the browser uses the CAC to access the
client certificate and private key. It then presents the certificate to the
appliance.
6. The appliance validates the certificate that the browser presents. This includes
the following checks:

The certificate must be issued by a CA in the CCL for the ProxySG


appliance service that is performing the validation.

The appliance confirms that the browser has the certificate's private key by
challenging the browser to sign random data. The appliance validates the
signature using the browsers certificate.

The certificate must have a valid signature and not be expired.

(If the appliance is checking for revoked certificates) The certificate must
not have been revoked.

7. If authentication succeeds, the appliance grants access to the Management


Console.
Chapter 2: "Configure Common Access Card Authentication" on page 9
explains authentication using the CAC. For more information on mutual SSL
authentication, refer to the SGOS Administration Guide.
Note: CAC authentication and Notice and Consent banners are supported in
FIPS mode and non-FIPS mode.

Chapter 1: Overview of Common Access Card Authentication

Requirements for CAC Authentication


CAC authentication requires:

(On the client workstation) Third-party software that typically includes a


driver for the card reader.

(On the ProxySG appliance) Configuration of the HTTPS console service,


which is already created in the Management Console. Configure the HTTPS
console service to validate the certificate that the client presents to the
ProxySG appliance.

(On the ProxySG appliance) A certificate realm.


The appliance verifies the client certificate during the SSL handshake. The
certificate realm retrieves the user identity from the certificate later, when the
appliance processes the <Admin> layers in policy.

(On the ProxySG appliance) Optionally, an LDAP realm.


The appliance uses information in the certificate to locate the user object in the
LDAP directory. Administrative rights are authorized based on information in
the user object, such as group membership.

Security Recommendations
For security reasons, advise users to:

Remove the CAC from the card reader whenever they step away from the
client workstation.

Close the browser (not just browser tabs) after they have logged out of the
Management Console.

What happens if authentication to a certificate realm fails


If authentication to the certificate realm fails, or if no realm has been configured
for authentication to the Management Console, the appliance prompts users for a
username and password. They can then enter the Management Console
credentials.
For more information on LDAP realm authentication and authorization, refer to
the SGOS 6.x Administration Guide.

What happens if authentication to a certificate realm is successful


If authentication to the certificate realm is successful, users can log in to the
appliance.
Note: Users require a PIN to access the private key on the CAC, but they might
not have to enter the PIN when they attempt to access the Management Console.
Specific steps that users must perform to authenticate to the Management Console
depend on the third-party CAC software on the workstation and whether or not
users have previously entered their PIN during the current session.
For more information on certificate realm authentication, refer to the SGOS 6.x
Administration Guide.

Common Access Cards Solutions Guide

Chapter 2: Configure Common Access Card Authentication

This chapter contains steps for configuring Common Access Card (CAC)
authentication for the Management Console and serial/SSH console.
The following table outlines the steps required to set up CAC authentication
through the Management Console to the ProxySG appliance, including an
optional step for setting up the Notice and Consent banner.
Perform the steps in the specified order, referring to the appropriate sections/
documents in the Instructions column.
Table 21

Set up CAC authentication

Step

Description

Instructions

Configure the ProxySG appliance for mutual SSL


authentication.

Locate instructions in the


Managing X.509
Certificates chapter in the
SGOS 6.x Administration
Guide.

Create a new keyring on the ProxySG appliance.


Import the server certificate and private key into the
keyring.
Alternatively, generate the key on the appliance and issue the certificate through a certificate signing request
(CSR).

Import client CA certificates.


Import the root CA certificate(s) and any intermediate
certificate(s) required to validate the client certificates on the
ProxySG appliance.

Add the client CA certificate(s) to a CA Certificate List (CCL)


on the ProxySG appliance.
Note: To validate the certificate presented by the browser, you
must specify a list of trusted CA certificate(s) in a CCL. For
best security, create a CCL to be used only for validating
administrative certificates. This CCL must contain at least the
root CA(s) for all valid administrative certificates. In some
cases, you might also have to import the intermediate CA
certificates.

Locate instructions in the


Managing X.509
Certificates chapter in the
SGOS 6.x Administration
Guide.
Locate instructions in the
Managing CA Certificate
Lists section in the
Managing X.509
Certificates chapter in the
SGOS 6.x Administration
Guide.

Common Access Cards Solutions Guide

Table 21

Set up CAC authentication

Step

Description

Instructions

(Optional) Set up a Notice and Consent banner.

Refer to the Notice and Consent


Banner Configuration Webguide
for instructions.

A Notice and Consent banner is a statement that you can


configure to display to users immediately before they log in.
The user must then acknowledge and agree to the statement
before they can be logged in.
The Notice and Consent banner is independent of CAC,
though you can use them together.
5

Create an HTTPS reverse proxy service to:

Use the keyring created in step 1.


Use the CCL created in step 3.
(For best security) Enable only TLS. When configuring the
service, select TLS protocols.
Require a client certificate.

Locate instructions in the


Configuring and Managing
an HTTPS Reverse Proxy
chapter in the SGOS 6.x
Administration Guide.

When configuring the service, select Verify Client. This setting


enables mutual SSL authentication for the Management
Console.
6

(Optional) Create an LDAP realm and point it at an Active


Directory (AD) or LDAP server.
For best security, configure secure LDAP (LDAPS). You must
use LDAPS if the appliance is running in FIPS mode.

Create a certificate realm.

Configure the realm for authentication.


(Optional) Configure the realm for authorization.

Note: Because certificate realms do not require an


authorization realm, users are not automatically members of
groups; to authorize via group membership, you can configure
an LDAP realm. Refer to the LDAP Realm Authentication and
Authorization chapter in the SGOS 6.x Administration Guide.
8

Write Content Policy Language (CPL) for authentication (and


authorization, if required).

10

Locate instructions in the


LDAP Realm Authentication
and Authorization chapter in
the SGOS 6.x Administration
Guide.
Locate instructions in the
Certificate Realm
Authentication chapter in
the SGOS 6.x Administration
Guide.

See Chapter 3: "Set up


Authentication and
Authorization" on page 11.

Chapter 3: Set up Authentication and Authorization

Chapter 3: Set up Authentication and Authorization

To complete configuration of Common Access Card (CAC) mutual


authentication, define authentication and authorization policy. You can use the
samples in this chapter as the basis for your own policies.
Note: You must configure CAC authentication in the Content Policy Language
(CPL); you cannot configure it through the ProxySG appliance Visual Policy
Manager (VPM).
After you have created the policy files containing the CPL for CAC
authentication, install them through the appliance Management Console
(Configuration > Policy > Policy Files) using any of the following methods:

Text Editor: Enter the CPL directly in the Text Editor or copy the contents
from an existing policy file and paste them into the Text Editor.

Local file: Install the CPL from a policy file that exists on a local directory.

Remote file: Install the CPL from a policy file that exists on a web server
that the appliance can access.

The ProxySG appliance compiles the new policy from all source files. If
compilation is successful, the policy is installed.
Note: After you click Install, the appliance displays a summary of any errors or
warnings that occurred while it attempted to compile policy. If errors occurred,
the policy file is not installed; fix the errors and then try to install the policy again.
Policy is installed if warnings occurred; however, some policy or features may not
work as you intended. Review the warnings and then take corrective action as
needed.

Prerequisite
Before installing CAC authentication policy, you must have completed the steps
in Table 21, "Set up CAC authentication" on page 9.

Tips for Writing Policy


Before you start:

Determine the name of the authentication realm as defined on the ProxySG


appliance.
When writing authentication policy in the <Admin> layer, specify the name of
this authentication realm.

(If applicable) Determine the name of the HTTPS reverse proxy service for the
Notice and Consent banner as defined on the ProxySG appliance (for
example, CAC-MC-Notify).

11

Common Access Cards Solutions Guide

(Optional if using LDAP to retrieve group memberships from Active


Directory) Decide if you want to use substitutions when creating the
certificate realm to extract the username from specific attributes in the
certificate. Refer to the appendix CPL Substitutions in the Content Policy
Language Reference for details on using substitutions.

Examples of CAC Authentication Policy


This section provides sample CPL as follows:

"CPL for CAC Authentication to the Management Console" on page 12

"CPL for CAC Authentication to the Serial/SSH Console" on page 13

To use similar policy in your deployment and ensure that it compiles, edit the
following samples for your specific configuration.

CPL for CAC Authentication to the Management Console


This is an example of policy for implementing CAC authentication to the ProxySG
appliance Management Console.
; Authentication to the Management Console
; In the "authenticate" actions below, replace the realm names
; with realms you have configured
<Admin> service.name=HTTPS-Console
; POST requests won't present the cookie, but we need to allow them
request.header.Content-Type.regex="multipart/form-data" authenticate(MC_AUTH_REALM)
request.header.Content-Type.regex="pod" authenticate(MC_AUTH_REALM)
DENY

12

Chapter 3: Set up Authentication and Authorization

CPL for CAC Authentication to the Serial/SSH Console


This is an example of policy for implementing CAC authentication to the serial or
SSH Console, with the optional LDAP realm configured.
Note: If you are authorizing users, change the group names in the following CPL
to the groups you have configured; otherwise, remove the group names
completely.
; Authentication for management interfaces other than the Management Console
; Replace SERIAL_SSH_AUTH_REALM with the authentication realm you set up
<Admin> service.name=!HTTPS-Console
authenticate(SERIAL_SSH_AUTH_REALM)
; Allow management interface access based on AD group membership
<Admin>
; Example for users from an LDAP realm
;
ALLOW admin.access=READ group="CN=RO-Admins,CN=Users,DC=bcaaa,DC=local"
;
ALLOW group="CN=RW-Admins,CN=Users,DC=bcaaa,DC=local"
; Example for users from a Local realm or an IWA-BCAAA realm
;
ALLOW admin.access=READ group="RO-Admins"
;
ALLOW group=RW-Admins
;
DENY
; Example for granting read-write access to all authenticated users
ALLOW authenticated=yes

13

Common Access Cards Solutions Guide

14

Chapter 4: Use Cases

Chapter 4: Use Cases

The use cases in this chapter describe how users log in using the Common Access
Card (CAC) in different environments:

"Use Case 1: Logging in to the Management Console" on page 15

"Use Case 2: Logging in to the SSH Console" on page 16

"Use Case 3: Logging in to the Serial Console" on page 17

Use Case 1: Logging in to the Management Console


In this example:

You configured an LDAP realm to communicate with Active Directory, and


client certificates contain a subjectAltName extension that holds the user's
Active Directory User Principal Name (UPN).

The certificate realm uses an LDAP realm for authorization; an LDAP search
using the following filter to determine authorization:
(userPrincipalName=$(user.name))

You use the substitution $(SubjectAltName.OtherName) to have the certificate


realm extract the username from the subjectAltName extension in the
certificate. This substitution expression is not case sensitive.
You can also use conditions such as group= and ldap.attribute.<name>= for
authorization and to specify whether users should have read-only or readwrite access.

You configured a Notice and Consent banner and provided users with the
banner address:
https://<IP_address>:<port>
where <IP_address> is the appliance IP address and <port> is the specific port
for the banner.

How the user logs in to the Management Console:

1. The user goes to the address of the Notice and Consent banner. The browser
displays the banner.
2. The user clicks the link to accept the banner statement. The Notice and
Consent action completes and the browser redirects to the Management
Console URL in a web browser:
https://<IP_address>:<port>
where <IP_address> is the appliance IP address and <port> is the specific port
for the Management Console.
The browser displays a dialog that shows the authentication certificate from
the users CAC.

15

Common Access Cards Solutions Guide

3. The user selects the certificate. They might be prompted for the CAC PIN,
depending on the CAC software on the workstation and whether the user has
recently logged in using the card.
The browser presents the selected certificate to the ProxySG appliance. The
appliance validates the certificate against the configured CA list. You can
configure the appliance to use Online Certificate Status Protocol (OCSP) or a
Certificate Revocation List (CRL) to check for certificate revocation.
For information, refer to the Checking Certificate Revocation Status in Real
Time (OCSP) and Using Certificate Revocation Lists sections in the
Managing X.509 Certificates chapter in the SGOS 6.x Administration Guide.
4. The certificate realm extracts the username from the SubjectAltName
extension in the certificate.
5. The LDAP realm searches for the user using the following filter:
(userPrincipalName=$(user.name))

The $(user.name) expression resolves to the subjectAltName value in the


client certificate.
6. If LDAP finds the user in the directory, the user is granted access to the
Management Console.
If LDAP does not find the username in the directory, the user is denied access
to the Management Console.
7. If groups are specified in policy, the appliance uses LDAP to determine if the
user belongs to the specified groups.

Use Case 2: Logging in to the SSH Console


In this example:

You configured an LDAP realm to communicate with Active Directory.

A Notice and Consent banner is configured.

How the user logs in to the SSH console:

1. The user starts an SSH client and enters the IP address of the ProxySG
appliance.
2. The SSH client connects to the appliance and displays the Notice and Consent
banner, followed by the password prompt.
Note: No formal consent is required; however, the users consent is implied
when they enter the password in the following step.
3. The user enters their Active Directory password.
4. LDAP retrieves the users group memberships and the user is granted access
to the SSH console.

16

Chapter 4: Use Cases

Use Case 3: Logging in to the Serial Console


In this example:

You configured an LDAP realm to communicate with Active Directory.

A Notice and Consent banner is not configured.

You have secured the ProxySG appliance serial console (users must enter their
credentials)

How the user logs in to the serial console:

1. The user starts a terminal client and enters the IP address of the ProxySG
appliance.
2. The terminal client connects to the appliance.
3. The user enters their Active Directory username and password.
4. LDAP retrieves the users group memberships and the user is granted access
to the serial console.

17

Common Access Cards Solutions Guide

18

Potrebbero piacerti anche