BlueCoat’s Guide to

Authentication V1.0

Blue Coat ® and the Blue Coat logo are trademarks of Blue Coat Systems, Inc., and may be registered
in certain jurisdictions. All other product or service names are the property of their respective owners.

© Blue Coat Systems, Inc. 2007. All Rights Reserved.

 Agenda
• Authentication, Authorization
• Authentication Modes
– Explicit mode authentication
– Transparent mode authentication
• Authentication Realms
– IWA
– Window SSO
– LDAP
– Novell
– Radius
– Local
– Certificate
– Substitution

2
 Authentication, Authorization,
Accounting

3
 Authentication

• Used on Proxy SG for :

– Authenticate device administrators
• Can be used to setup authorization rules
• Configuration modifications logs

– Authenticate users surfing to Internet

• Used for logging
• Used to build a policy based on users

– Authentication is a two levels architecture :

• Proxy mechanism to challenge the user
• Authentication Realm used to validate credentials

4
 Authorization

• Device’s administrators
– Two profiles available today :
• Read only
• Read/write

• Users surfing to Internet

– Can build a policy based on :
• Usernames
• Groups
• Attributes

– Reporting
– Exceptions tuning

5
 Authentication Modes

6
 HTTP RFC
• Two HTTP challenges (challenges mode) are available :
– 401 : www-authenticate : authenticate on a resource
– 407 : Proxy-authenticate : proxy asks for auth.

• Credential are replayed by the browser in the same session :

– For the same destination with 401
– For every requests with 407

• Type of challenges can be :

– Basic
– NTLM
– Negotiate (Kerberos)

7
 Blue Coat Terminology

• Need to understand differences between proxy’s

deployment mode regarding the authentication mode
• Proxy can be setup as :
– Explicit proxy
– Transparent proxy
• Authentication mode can be :
– Explicit mode : proxy, proxy IP
– Transparent mode : origin (ip/cookie), origine-redirect
(ip/cookie), form (origin/cookie), form-redirect
(origin/cookie)
• An explicit proxy architecture can use transparent mode
authentication (but not really recommended)

8
 Blue Coat Terminology

• Authentication mode syntax :

– Mode-surrogate[-redirect]
• Mode can be :
– Proxy
– Origin
– Form
• Surrogate can be :
– IP
– Cookie (session or time based)
• Redirect means the user will be challenged and
redirected on the virtual url

9
 Proxy Authentication

• 407 Proxy Authentication Required

– Indicates that the client must first authenticate itself with the
proxy
– The proxy MUST return a
Proxy-Authenticate header field
– The client MAY repeat the request with a suitable Proxy-
Authorization header field
• Cannot be used in transparent deployments

10
 Server Authentication

• 401 Unauthorized
– The request requires user authentication. The response
MUST include a WWW-Authenticate header field
– Used for Web Server Authentication
– Authentication cached separately per each resource
• Proxy cannot challenge the user agent
– HTTP 407 are ignored
• Cache Authentication Information : Surrogate
– Avoid challenging the user agent multiple times

11
 Surrogate

• It’s the proxy’s way to memorize an already authenticated

user.
• Can be used to limit the impact on Authentication
architecture in high volume deployment
• TCP session is the default surrogate
• In proxy mode authentication :
– Only IP can be used : proxy-IP
• In transparent mode authentication :
– IP
– Cookie
• Session
• Time based

12
 Authentication modes best practice

Proxy Origin Form Origin Challenge Form Challenge with

Challenge Challenge Challenge with redirection redirection

TCP proxy origin - - -

connection
Surrogate

Cookie - origin-
origin- form-cookie origin-cookie-
origin- cookie- form-cookie-redirect
Surrogate cookie redirect

IP Surrogate proxy-ip origin-ip form-ip origin-ip-redirect form-ip-redirect

Explicit Reverse Proxy Transparent Proxy

Proxy
13
 When to use ?

• Proxy mode : explicit proxy architecture

• Proxy-ip : explicit proxy when SG sees client ip
• Origin/form[ip/cookie] : reverse proxy when you don’t
need single auth for different servers
• [Origin/form]-redirect :
– transparent proxy auth
– Reverse proxy when single auth needed
– Secure basic credential in proxy mode (AT RISK)

14
 How to setup ?

• Using VPM in authentication layer

– Authenticate
– Force_authenticate

15
 Specific modes

• Auto means : proxy chooses the mode depending of the

connection type
– Proxy : in explicit mode
– Origin[cookie/ip] : in transparent mode
• SG2 : legacy auto on SG2
– Use ip surrogate for IWA proxy mode

16
 Downgrade rules

• Streaming requests are switched to origin challenges ?

• If the challenge type is “origin-redirect”, but the client doesn’t

understand redirects, switch to “origin” including:
– Non-HTTP requests
– Streaming clients (even over HTTP)
– POST or PUT from browsers that don’t support 307 redirects
– POST or PUT with mime-type multipart/form

• If the surrogate credential is set to “cookie”, but the client

doesn’t support cookies, downgrade to “ip”
– Non-HTTP requests
– Streaming clients (over HTTP)

17
 The Tricky part : Origin cookie Redirect

• Why : In transparent proxy architecture

• you cannot just use 401 : will challenge every domain
• You cannot just set a cookie : cookie are per resource
(host, domain, path)
• You need to globally authenticate your user for all
Internet.
• How :
– redirect a user on a Virtual Url (VU)
– Authenticate the user on the VU
– Redirect the user from the VU
– Use a surrogate to limit performance impacts

18
 How to setup ?

• Global VU setting in Authentication/Transparent

• In Authentication/ Realm/General

Virtual Url

19
 Origin Cookie Redirect : phase 1

20
 Origin Cookie Redirect : phase 2
on a different domain

21
 Origin Cookie Redirect : phase 3
on the same domain

22
 Origin Redirect for explicit proxy

• Why ?
– Certificate Realm
– Siteminder
– Secure credential (HTTPS VU)
• Why not ?
– Not working with Connect Method (explicit https requests)
– Not working with applets, bots, apps …
– Not working with POST method (limited)
– Need to exclude the VU from browser configuration

23
 Authentication cache

24
 Authentication Cache

• Used to limit authentication impact on the architecture

• 3 levels cache (in 5.X, just one cache with 4.X) :
– Credential
– Surrogate
– Authorization
• Cache is define per Realm (5.X, global with 4.X)
• Cache time is customizable
• Cache can be flush (in statistics tab with 5.X)
• 4.X has a 80000 entries limit, starting flushing at 20000

25
 Authentication Cache

• Configuration Screenshot

Cache :
• credential
• surrogate
• authorization

26
 Credential cache

• Amount of time basic credentials are memorized

• Basic credentials are login and password asked for basic
type of challenges (not NTLM, Kerberos …)
• Default time is 900 secs (15 mins)
• During this period user’s credentials are compared to
cached credentials
• If password mismatches, proxy will re validate to the
server (may be a password change)
• Cached credentials can be forwarded to server (cli
command in forwarding sub menue)

27
 Surrogate Cache

• Surrogate is an information identifying an authenticated

user
• During the surrogate life time, user’s sessions are never
challenged
• If you clear surrogate cache users will be re challenged
• Two main surrogates :
– Ip address : source ip seen in the tcp session
– Cookie : cookie set by the proxy
• Cookie mode only available with http (https)

28
 Authorization Cache

• Concerns groups and attributes

• Only available for realms having such notions (ldap for
ex)
• Proxy will remember
– Groups information
– attributes

29
 Form specific information

• SG can challenge a user with a form instead of

401/407/30x
• Form is an exception
• Form content can be customized
• If user is challenged during a POST request, SG can
memorize Post’s content to replay it after authentication :
request storage

30
 Authentication Realms
IWA

31
 IWA
• Stands for Integrated Windows Authenticate
• Leverage on existing Microsoft SSO features
• 3 challenges types available : Basic, NTLM, Negotiate (Kerberos)
• Basic is a fallback method if non windows client
• ProsySG is not part of Windows Architecture !
• We use an agent to relay authentication challenges :
– BCAAA : Blue Coat Authentication and Authorization Agent
– Can be installed on Windows machine or Solaris (4.X)
– Using an Agent is a Microsoft’s advise :

Microsoft SSPI:
“The Microsoft® Security Support Provider Interface (SSPI) is the well-defined common API for obtaining
integrated security services for authentication, message integrity, message privacy, and security quality of
service for any distributed application protocol. Application protocol designers can take advantage of this
interface to obtain different security services without modification to the protocol itself.”
“Microsoft encourages all Win32 application developers to use the integrated security features of SSPI for
secure distributed application development.”
Microsoft White Paper, The Security Support Provider Interface.
32
 IWA : NTLM
• No specific needs for user’s right running the agent process
• NTLM is a per session authentication mechanism
• No credential cache available (challenges)
• NTLM is a three way challenge (try to use surrogate)
• General Architecture :

Browser Proxy BCAAA Domain Controller

Request – No Auth

Auth Challenge

NTLM Negotiate NTLM Negotiate Data Windows API

Call w/NTLM Data Negotiation
NTLM Challenge NTLM Challenge Data NTLM Challenge Data

NTLM Response NTLM Response Data Windows API

Call w/NTLM Response Data
Requested Data Auth Confirmation Auth Confirmation

33
 IWA : Kerberos

• Kerberos is future Microsoft’s SSO norm

• More secure than NTLM ?
• Uses key exchange/ Tickets based on clock
• Use the same BCAAA architecture
• Needs special right to install agent : “act as operating
system”
• Kerberos only works with Transparent mode
authentication (redirect)
• Need to register the VU on the DC with setspn command

34
 IWA troubleshooting
• Good luck …
• Try browsing via VPM
• User’s rights for BCAA service (check documentation)
• When using transparent auth modes (for NTLM or by default with
kerberos)
– By default web web browser's security only respond to SSO challenges on
intranet urls
– Intranet urls are :
• non FQDN urls (ex : intranet)
• IP addresses
• Urls in the intranet security list of IE options
– This behavior can be changed for ie in options tabs
– Can be changed in Firefox in about:config
• Advanced logs for BCAAA :
– [Debug] DebugLevel=0xffffffff

35
 IWA : NTLM & Kerberos caveats

• Verbose protocol , try using surrogate

• Not supported on most non IE apps (except Firefox ?)
• Proxy will log last group matched in policy :
– Group of interest list can be ordered in VPM
– VPM : configuration / set group log order
• Try avoiding kerberos in explicit mode.
• Multiple Windows domains need bi-directional trust
relationships or multiple realms.

36
 Authentication Realms
Windows SSO

37
 Windows SSO

• Windows SSO is not IWA

• Windows Active Directory networks (Novell eDirectory is
Novell SSO)
• Available on 4.2.2
• IP address based
• Uses BCAAA to acquire mapping of IP address to User
name
• User logs into the workstation and then is never
challenged
• Works with all protocols

38
 Windows SSO : version’s specific

• Authorization is done with an LDAP query of the FQDN

on the AD server
• In 4.2.2, Windows SSO only provided the NetBIOS
username and domain
– In most cases customers cannot properly map the NetBIOS
name to an AD FQDN
• 4.2.3 provides the FQDN
– Select “Use FQDN” for Authorization

39
 Windows SSO: How it Works

• Two methods are used to determine the user logged

onto a workstation
– Domain Controller Querying
– Client Querying
• The methods can be used separately or together

40
 Domain Controller Querying

• Domain Controller Querying discovers the domain

controllers in the forest
• Each domain controller is then frequently queried for the
current set of authenticated connections
• This is used to build up a table of IP addresses to
authenticated users

41
 Domain Controller Querying II

• Only captures logons, not logouts

• Only captures logons authenticated against a domain
controller
• BCAAA must run as a domain user to be able to query
Windows 2003 domain controllers
• Data is transient, if BCAAA goes down then new logons are
missed
• All logons are written to a file which restores the state after a
restart
• In 4.2.3, two BCAAA’s can synchronize each other
• Configuration requires editing “sso.ini” file in the BCAAA install
directory
– DCQEnabled=1

42
 Client Querying

• Client Querying works by remotely reading the

Workstation registry to see who is logged on
• Can solve several of the weaknesses of Domain
Controller Querying
• Does not need persistent state or synchronization

43
 Client Querying II

• Reading the registry requires BCAAA to run as a domain

user
• Windows XP (and greater) firewall blocks registry read
requests
• Need to set up a group domain policy to open up the
firewall (if it is being used)
• Does not work with non-Windows or Win 95/98/ME
• Configuration requires editing “sso.ini” file in the BCAAA
install directory

44
 Authorization

• Windows SSO just provide identification

• Mechanism doesn't provide groups information
• Need to use Realm’s Authorization tab :
– Create a LDAP Realm
– Use LDAP for authorization
– Need to map username to LDAP FQDN
– Group based policy use Windows SSO Realm
• When defining a group based policy just create a group
object from the windows sso realm.

45
 Gotcha’s

• Need to run BCAAA as a domain user

• BCAAA’s domain user should be listed as a service user
• Existing SSL certificate problem
• Windows 2003 SSL privilege problem
• Need to carefully limit which domain controllers are
queried

46
 Authentication Realms
LDAP

47
 LDAP

• We have a nice LDAP client (never been a blocking

LDAP scheme)
• LDAP can only use Basic type challenge
• No SSO
• LDAP is not secure between client and proxy unless
using origin redirect on https vu (AT RISK)
• LDAP config propose 3 default schemes (AD, sun,
novell)
• Nested groups are supported
• Groups membership can be modified

48
 LDAP SGOS 4

• How it works with SG4:

1. SG challenges the user
2. User sends basic
3. SG connect to LDAP server with search
user/anonymous
4. SG searches for the user
5. SG connects with user account
6. SG compares attributes

49
 LDAP SGOS 5

• How it works with SG5:

1. SG challenges the user
2. User sends basic
3. SG connect to LDAP server with search
user/anonymous
4. SG searches for the user
5. SG connects with search user account
6. SG compares attributes

50
 How to setup ?
• In authentication/LDAP Realm
– LDAP version
– LDAP server’s type
(AD, Novell, Sun, other)
– Server ip address
– LDAP DN
– LDAP search user
– LDAP user attribute

51
 Known LDAP limitations

• One compare request for all groups and attributes rules

matched in policy
• No Regex on attribute (NetCache feature no more on
roadmap)
– Attribute.userrigths=“.*1011.*”
– Next LDAP version should permit to retrieve all users
information and to test it locally

52
 Authentication Realms
Novell SSO

53
 Novell SSO

• Customers who use Novell eDirectory want a single

sign-on (SSO) solution
• Want users to be able to login to Novell client and then
be authenticated by the SG without being challenged
• IP address based
• Works with BCAAA version 120 (4.2.3)

54
 Novell SSO: eDirectory Login

• How Novell client logins work

– User logs in with the Novell client which updates the
eDirectory user’s networkAddress attribute with the IP
address (and port) that they logged in from
– There is a networkAddress value for each IP address that
the user has logged in from
– When a user logs out, the networkAddress value for that
login is removed.

55
 Novell SSO: Realm

• Authentication:
– BCAAA is used to make LDAP queries on the eDirectory
server to map IP addresses to user's FQDNs
– When a user makes a request to the SG, the SG queries
BCAAA for the user identity corresponding to the client IP
address
• Authorization:
– The Novell SSO realm uses BCAAA to query the eDirectory
server via LDAP
– An LDAP realm is used by the Novell SSO realm for
eDirectory LDAP config
– Authorization can be performed with the eDirectory server
or with separate authorization server

56
 Novell SSO: BCAAA

• BCAAA version 120 (4.2.3)

• BCAAA uses LDAP APIs for Novell SSO
– BCAAA authenticates via an LDAP bind
– Credentials are from the search user defined in the Novell
SSO LDAP realm
– BCAAA can run as LocalSystem and the machine does not
require special trusts

57
 Novell SSO: BCAAA Details

• BCAAA queries the root eDirectory server for all users

that are currently logged in (following referrals as
necessary)
– The query searches for all users that have a
networkAddress attribute
• The search results are then used to create a list of IPs to
user FQDNs

58
 Novell SSO: BCAAA Details

• BCAAA maintains the list in two ways

– Monitors the configured servers for login and logout events
• When an event is received, it adds and removes login entries as
appropriate

– Does a full query of the eDirectory server at configurable intervals

• Determine the eDirectory structure

– Each separate tree requires a separate Novell SSO realm
– Determine the root server for each tree
• This will be the server for the Novell SSO LDAP search realm

– Determine how the partitions are replicated

• Monitor servers which contain partitions that are not replicated to the
root server

59
 Novell SSO: Server Relationships

LDAP Realm
(Search and Monitor)
BCAAA eDirectory Server

ProxySG

Users
60
 Novell SSO: LDAP Realms Relasionship

1. Create an LDAP realm for each master eDirectory

server
2. Create a Novell SSO realm for each of the LDAP
realms
• each Novell SSO realm points to one LDAP realm

61
 How to setup ?

• Specify agent ip and key

password if SSL
• LDAP Edirectory for search req
• Mapping updates

62
 Authentication Realms
Radius

63
 Radius

• Rarely used
• No specific configuration
• Mainly for administrators authentication
• Can support OTP (One Time Password)
– Secure Safeworld, RSA
– Only http is supported
– Use form authentication
• No group support
– Need to use attribute : Blue-Coat-Group
– BC Vendor ID: 14501, attribute vendor type: 1

64
 Authentication Realms
Local Authentication

65
 Local Authentication

• Proxy SG can use a local user database for

– Authentication
– Authorization
• Each Local Realm needs a local-user-list
– Users
– Groups
• Local user list provisioning :
– Cli commands
– Scripts
• Groups cannot be browsed via VPM

66
 Local User List

• One script available :

– Perl Script
– set_auth.pl
– Takes as input a file text and push it to SG via HTTP
– Text file is .htpassword style :
• Login:encrypted_password group1, group2, …
• On user per line
• Password is encrypted UNIX DES or MD5
• Plaintext password < 64 caracters

67
 How to setup

• Local-user-list
• Credentials cache
• VU

68
 Authentication Realms
Certificate

69
 Certificate Realm

• Use X509 certificates

• Identify user
• Can be authorized with :
– LDAP Realm
– Local Realm
• Certificate cannot be forwarded to OCS
– Specifics information can be fwd in a header
• Installed certificate must be in PEM format
• Need origin style challenge

70
 Revocation List

• Two types of CRL :

– Via policy and certificate’s serial numbers
– With external CRL List
• List contains revocated certificates

• OCSP will be available in 5.3

71
 Setup Certificate Realms

• How to setup :
– Origin style challenge
– HTTPS virtual url if redirect used
– HTTPS service with verify-client attribute
– Create/install a server certificate
– Attach the correct server certificate on the service
– Create a Certificate Realm
– Install PKI root CA
– Use a Authorization Realm if needed

72
 Authentication Realms
Policy Substitution

73
 Policy Substitution

• When user cannot be challenged !

– Non human client
– No understanding of http challenges
– Cannot prompt for login/pwd
– Hierarchical proxy already authenticated on first level

• 4 mechanisms :
– NetBIOS
– RDNS
– Header
– Ident

• Can use Authorization Realm

74
 How to setup ?

• In authentication/substitution Realm :
– Specify the policy substitution cpl code

User based on header

75
 Substitution

• Most useful example is hierarchical architecture

– Central group based policy
– Central reporting

Authentication Server Authorization Server

Authorization
challenge
For username

WAN Internet
Users Lvl1 ProxySG Lvl2 ProxySG

Authentication Challenge Get /url

X_header : username
76
 Authentication Realms
Sequence Realm

77
 Sequence realm

• Users are in different directories

• Cannot specify a source condition in VPM
• Sequence realm permit to
– Specify multiple realms as a single one
– Challenge once the user
– Once basic are received, used them with different servers
• Specific :
– Only 1 IWA (first or last)
– No certificate realm
– Need SGOS 5.2 to tolerate errors

78
 Sequence mechanisms

79
 How to setup ?

• Specify realms
list :
– Iwa first
– Then ldap
– Then local
• Tolerate errors

80
 Authentication Realms
Guest users

81
 Guest users

• Useful to handle :
– Guest users
– Non domain users
– Wifi subnets
– Authentication server errors
• User can be assigned as a guest
• Guest user can be assigned to a group
• Guest user name is customizable
– Ex: guest_$(c-ip)

82
 How to setup ?

• Creat a VPM
authentication
layer
• Specify :
– Username
– Realm

83
 Authentication Realms
Tolerate errors

84
 Errors Handling

• SGOS 4 :
– if any authentication or authorization errors : Deny
• SGOS 5 :
– Deny by default
– Can specify tolerated errors :
• Authentication errors
• Authorization errors

• Be carefull on what an error is

– Cf TD on BCAAA agent unavailable and timeout (process
VS network)

85