DIGIPASS Authentication for Blue Coat ProxySG - VASCO · DIGIPASS Authentication for Blue Coat...

DIGIPASS Authentication for Blue Coat ProxySG - Integration Guideline V1.0 2010 VASCO Data Security. All rights reserved. of 20

DIGIPASS Authentication for Blue Coat ProxySG

With IDENTIKEY Server

Integration Guideline


Disclaimer Disclaimer of Warranties and Limitations of Liabilities This Report is provided on an 'as is' basis, without any other warranties, or conditions.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of VASCO Data Security.

Trademarks DIGIPASS & IDENTIKEY are registered trademarks of VASCO Data Security. All trademarks or trade names are the property of their respective owners. VASCO reserves the right to make changes to specifications at any time and without notice. The information furnished by VASCO in this document is believed to be accurate and reliable. However, VASCO may not be held liable for its use, nor for infringement of patents or other rights of third parties resulting from its use.

Copyright 2010 VASCO Data Security. All rights reserved.


Table of Contents

DIGIPASS Authentication for Blue Coat ProxySG ............................................ 1

Disclaimer ...................................................................................................... 2

Table of Contents............................................................................................ 3

1 Overview ................................................................................................... 4

2 Problem Description .................................................................................. 4

3 Solution .................................................................................................... 4

4 Technical Concept ..................................................................................... 5

4.1 General overview .................................................................................. 5

4.2 ProxySG prerequisites ............................................................................ 5

4.3 IDENTIKEY Server Prerequisites .............................................................. 5

5 Blue Coat ProxySG .................................................................................... 6

5.1 RADIUS configuration ............................................................................ 6

5.2 IWA configuration .................................................................................. 7

5.3 SSL configuration .................................................................................. 8

5.4 Virtual policy configuration ....................................................................10

6 BCAAA Agent ........................................................................................... 12

6.1 Installation ..........................................................................................12

6.2 Delegation Settings ..............................................................................13

6.3 SSL certificate ......................................................................................14

7 IDENTIKEY Server ................................................................................... 15

7.1 Policy configuration ..............................................................................15

7.2 Client configuration ..............................................................................18

8 About VASCO Data Security .................................................................... 20


1 Overview The purpose of this document is to demonstrate how to configure IDENTIKEY Server to work with Blue Coat ProxySG in combination with Kerberos constrained delegation.

ProxySG delivers a scalable proxy platform architecture to secure Web communications and accelerate the delivery of business applications. ProxySG enables flexible policy controls over content, users, applications and protocols and is the choice of more than 80% of the Fortune® Global 500.

2 Problem Description The basic working of the ProxySG is based on authentication to an existing media (LDAP, Radius, local authentication …). To use the IDENTIKEY Server, in combination with Kerberos constrained delegation to a microsoft back-end like OWA, the RADIUS and IWA settings on the ProxySG need to be changed or added manually.

3 Solution After configuring the IDENTIKEY Server and ProxySG in the right way, you eliminate the weakest link in any security infrastructure – the use of static passwords – that are easily stolen guessed, reused or shared.

Figure 1: Solution


4 Technical Concept 4.1 General overview One of the advantages of the Blue Coat ProxySG is to perform authentication when making a secure connection. As the ProxySG can authenticate to an external service with RADIUS, we will place the IDENTIKEY Server as middleware or as back-end service, to secure the authentication with our proven IDENTIKEY software. As a second authentication a Kerberos ticket will be generated on the domain controller.

4.2 ProxySG prerequisites Please make sure you have a working setup of the ProxySG. It is very important this is working correctly before you start implementing the authentication to the IDENTIKEY Server.

For this document, we used SGOS version 5.4.3.3. Older or newer versions will be compatible with minor differences in certain areas.

To be able to use the Kerberos constrained delegation, the domain functional level must be raised to Windows Server 2003. If you have any Windows 2000 Server running as domain controller, you may NOT raise the domain functional level.

4.3 IDENTIKEY Server Prerequisites In this guide we assume you already have IDENTIKEY Server installed and working. If this is not the case, make sure you get it working before installing any other features.


5 Blue Coat ProxySG 5.1 RADIUS configuration First of all we create a new RADIUS Realm. Fill in the Primary Server as the first IDENTIKEY Server. Click the Change Secret button to set the shared secret. Also important to enable is the One-time passwords checkbox.

Figure 2: RADIUS configuration


5.2 IWA configuration Next we have to create a new IWA realm, which will be responsible for making the Kerberos ticket. Fill in the Primary server host and make sure the Enable SSL checkbox is checked. Important here is to uncheck the Allow Basic credentials checkbox and to check the Allow Kerberos credentials checkbox.

Figure 3: IWA configuration


5.3 SSL configuration The SSL configuration is necessary for the communication with the BCAAA agent.

First we have to create a new Keyring. Make sure there is also a certificate bound to the keyring. This can be a self-created certificate.

Figure 4: SSL configuration (1)

As a side step, we will now select the appliance-key from the Keyring list, copy the certificate text and create a new .crt file (paste the text in a textfile and rename to .crt). We will need to import this certificate later on the BCAAA agent server.



Next we have to create a new Device Profile for the IWA SSL connection. Make sure that the protocol is SSLv3TLSv1. The keyring is the one you created in the steps above.



5.4 Virtual policy configuration Now it’s time to create the policies. Make a new Web Authentication policy that triggers the access of the OWA server. Different approaches are possible here. What matters in this case is the Action that is attached to this rule.

Right click the Action and select New Combined Action.

Figure 7: Virtual policy configuration (1)

First we want to perform RADIUS authentication so add the RADIUS authentication realm, and as second add a Kerberos Constrained Delegation action to the IWA server. (In the next step you can see the details configuration.)



For the RADIUS properties, select the correct Realm and set the Mode to Origin.

For the Kerberos settings, make sure that Authentication Type is set to Origin and de correct realm has been selected. Very important here is the Service Principal Name. This has to be the SPN of the server where the BCAAA agent will be installed.



Also create a Web Access: Access Policy to allow the traffic to be proxied through the reverse proxy rule once the user is authenticated


And the last part is to create a Forwarding Layer: Reverse Proxy rule to make sure the traffic is routed from the ProxySG to the OWA server.



6 BCAAA Agent 6.1 Installation Install the BCAAA agent on a domain controller with the following options:

• SSL Requirements: Required • Certificate Subject: If the ProxySG is using a DNS name to communicate with

the BCAAA server, you have to enter the server name. If the ProxySG is using an ip address, then you have to enter the ip address of the BCAAA server.

• Save generated certificate: Yes • Verify ProxySG Certificate: Yes • Service Account: Local System account


6.2 Delegation Settings A few things are important when talking about Kerberos constrained delegation.

• The domain functional level has to be Windows Server 2003. If you still use any Windows 2000 Server as domain controller, you may NOT raise the domain functional level and you will not be able to use the delegation options.

Figure 13: Delegation Settings (1)

• Next point is to add the delegation for the http service to the computer where the BCAAA agent is installed. Always Use any authentication protocol.

Figure 14: Delegation Settings (2)


6.3 SSL certificate At this point you have to import the certificate that was created in chapter 5.3 SSL configuration. Make sure you add this certificate to the certificate store of the computer and not the authenticated user. Start Run MMC Add Snap-In Add… Certificates Computer account.

Now, import the .crt file into the Trusted Root Certification Authorities.

Figure 15: SSL certificate


7 IDENTIKEY Server Go to the IDENTIKEY Server web administration page, and authenticate with and administrative account.

7.1 Policy configuration To add a new policy, select PoliciesCreate.

Figure 16: Policy configuration (1)

There are some policies available by default. You can also create new policies to suit your needs. Those can be independent policies or inherit their settings from default or other policies.


Fill in a policy ID and description. Choose the option most suitable in your situation. If you want the policy to inherit setting from another policy, choose the right policy in the Inherits From list. Otherwise leave this field to None.


In the policy options configure it to use the right back-end server. This could be the local database, but also active directory or another radius server.

This is probably the same that was in your default client authentication options before you changed it. Or you use the local database, Windows or you go further to another radius server.

In our example we select our newly made Demo Policy and change it like this:

• Local auth.: Digipass/Password • Back-End Auth.: Default (None) • Back-End Protocol: Default (None) • Dynamic User Registration: Default (No) • Password Autolearn: Default (No) • Stored Password Proxy: Default (No) • Windows Group Check: Default (No Check)

After configuring this Policy, the authentication will happen locally in the IDENTIKEY Server. So user credentials are passed through to the IDENTIKEY Server, it will check these credentials to its local user database and will answer to the client with an Access-Accept or Access-Reject message.


In the Policy tab, click the Edit button, and change the Local Authentication to Digipass/Password.


The user details can keep their default settings.



7.2 Client configuration Now create a new component by right-clicking the Components and choose New Component.

Figure 20: Client configuration (1)


As component type choose RADIUS Client. The location is the IP address of the client. In the policy field you should find your newly created policy. Fill in the shared secret you entered also in the client for the RADIUS options. In our example this was “vasco”. Click Create.

Figure 21: Client configuration (2)

Now the client and the IDENTIKEY Server are set up. We will now see if the configuration is working.


8 About VASCO Data Security VASCO designs, develops, markets and supports patented Strong User Authentication products for e-Business and e-Commerce.

VASCO’s User Authentication software is carried by the end user on its DIGIPASS products which are small “calculator” hardware devices, or in a software format on mobile phones, other portable devices, and PC’s.

At the server side, VASCO’s VACMAN products guarantee that only the designated DIGIPASS user gets access to the application.

VASCO’s target markets are the applications and their several hundred million users that utilize fixed password as security.

VASCO’s time-based system generates a “one-time” password that changes with every use, and is virtually impossible to hack or break.

VASCO designs, develops, markets and supports patented user authentication products for the financial world, remote access, e-business and e-commerce. VASCO’s user authentication software is delivered via its DIGIPASS hardware and software security products. With over 25 million DIGIPASS products sold and delivered, VASCO has established itself as a world-leader for strong User Authentication with over 500 international financial institutions and almost 3000 blue-chip corporations and governments located in more than 100 countries.

DIGIPASS Authentication for Blue Coat ProxySG - VASCO · DIGIPASS Authentication for Blue Coat...

Documents

Transcript of DIGIPASS Authentication for Blue Coat ProxySG - VASCO · DIGIPASS Authentication for Blue Coat...