In the circuit you can see below, I am doing four things:

1) Authenticating the client against an LDAP directory (in this case Microsoft Active Directory) using WS-Security UsernameTokens.

2) Looking up attributes for the user (in this case, their telephone number)

3) "Injecting" a SAML 2.0 assertion into the message, including the SAML Attribute Statement

4) Passing the message back, with the SAML assertion now in it (so that we can see it). Here I could have used a "Connect to URL" filter to send the message to a URL, the "Messaging" filter to put it onto a queue, etc.


Let's look at each of these filters. Firstly, the filter which does WS-Security authentication against LDAP. This is shown below:


See that "Sample Active Directory Repository" under the "Repository Name" field above? That is a pointer to the connection I have configured to an LDAP directory. Actually, with the Vordel Gateway, you get a pre-configured sample LDAP connection which you can adapt to your own directory. This is what I did. The configuration for the LDAP connection can be found under "External Connections", as shown below:

You can see above that there are two things to configure: (a) The Authentication Repository Profile, and (b) The LDAP Connection itself. The LDAP Connection is how the Gateway binds to the LDAP server. The Authentication Repository Profile is how it finds the users which are being authenticated. So it is "bind then find". The Authentication Repository Profile (the "find") makes use of the LDAP connection (the "bind"). Note that if you only configure the LDAP connection, you won't see your LDAP authentication connection come up in the drop-down box on your authentication filters.

If I click on "Add/Edit", I can edit (and test) my LDAP connection. In the screenshot below, you can see that the test was successful, meaning I could connect from Policy Studio to the LDAP directory:


OK - so now let's look at the next filter in our circuit. This is a "Retrieve Attributes from Directory Server" filter, which you can find in the "Attributes" group in Policy Studio. I have configured it to retrieve the "telephoneNumber" filter from Active Directory:

If I look into Active Directory, I can see the phone number is in place for a sample user ("Joe Developer"). This is the phone number I am looking up:


Next, I am using an "Insert SAML Authentication Assertion" filter, and I have checked the box to place the SAML Attributes into it, as shown below:


So.... Now when I send a request to the Gateway on a path which is mapped to that policy (e.g. /MyAPI), I see that in the response I now have the SAML Assertion containing the user's phone number. Note that the WS-Security UsernameToken has been removed after use by the Vordel Gateway (you might have noticed the checkbox for this in the WS-Security configuration screenshot above).