How to configure SAML authentication on the ProxySG with AD FS

book

Article ID: 179163

calendar_today

Updated On:

Products

Advanced Secure Gateway Software - ASG ProxySG Software - SGOS ASG-S200 ASG-S400 ASG-S500 SG-S400 SG-VA SGVA

Issue/Introduction

 

Resolution

This tutorial will show you how to configure a SAML (Security Assertion Markup Language) Realm authentication on the ProxySG when using Active Director Federation Services (AD FS).

Additional Information

DESCRIPTION :

The fist step that you would need to take is to create an HTTPS Reverse Proxy Service for the Virtual Host URL that will be used in the SAML Realm:Configuration > Services > Proxy Services > New

The reason why you use port 4433 is so that it does not conflict with any other HTTPS Reverse Proxy Service you have running on port 443.

 

Now you can create the SAML Realm.

Configuration > Authentication > SAML > New

Under the option "Federated IDP metadata URL" you will need to enter the URL for the Metadata.xml file. This is held on the AD FS under the path.

AD FS > Services > Endpoints > scroll to the bottom 

Once the Metadata.xml file has been loaded you will find that some of the option are auto completed for you.

You will now need to set the Virtual Host URL, this is the URL that the ProxySG will forward the client connections to for the authentication. For this example we will use https://proxy:4433 the host "proxy" will resolve to the IP of the ProxySG.

 

Now that you have created and configured the SAML Realm on the SG you now need to perfrom some configuration action on the AD FS.

Once you have started the wizard for AD FS you will need to provide the "Federation Metadata Address".

This is the URL that the AD FS will use to load the Metadata.xml file from the ProxySG.

https://:8082/saml/metadata//sp

You can also use the URL directly in a browser to download the Metadata.xml file and then manually upload the file to the AD FS.

Once you have either provided the correct URL for the Metadata.xml file or have uploaded the file you then need to supply a "Display Name".

For this deployment scenario the default option "Permit all users to access this relying party" has been selected.

 

Then client > Next > Next > Finish

 

Now that the AD FS has had the ProxySG added as a "Trusted Rely" you now need to add a "Claim Rule". A "Claim Rule" is where you will configure what data is sent in the assertions. Assertions are the data the AD FS will send back to the ProxySG regarding the user authentication request.

In this scenario the first "Client Rule" you will be adding is based on the client username:

So you select the "Relaying Party Trust" that you have created and then Select "Edit Claim Rules".

You will want to select "Add Rule" where you will be provided the "Claim Rule Wizard".

You will want to select the default "Client rule template" which is "Send LDAP Attributes as Claims".

You will need to set a name for the "Claim Rule", this name can be anything you wish to use. The "Attribute Store" needs to be set to "Active Directory".

For the "LDAP Attribute" use the drop down option and select "User-Principal-Name". For the "Outgoing Claim Type" use the drop down option and select "Name ID".

Then select "Finish".

 

You will also need to Impart the "Token-signing" Certificate on to the ProxySG so the ProxySG is able to decrypt the Assertions.

The Certificate needs to be imported in to the CA Certificates list on the SG and placed in to the CA Certificate List that you are set to use (in most cases this is the "Browser-Trusted").

Now that both the AD FS and the SAML Realm have been configured all that need to be done is to configure the Visual Policy Manager (VPM) to use the new SAML Realm for the Reverse Proxy.

So the first rule is the Web Authentication Layer Rule where you specify the "Action" to be the new SAML Realm that has been created.

Then you need to specify the User Account that you will want to allow access.

Now any inbound connection to the ProxySG will be subject to the SAML Authentication Realm. You can further lock down the rule base by controlling the Destination Trigger as well on the rule.

Attachments