SSO with SAML 2.0 (ADFS) config

#1

hello folks,

has anyone configured Dundas to work with SSO & SAML 2.0 as the protocol (w/ ADFS)?
I've followed up the Dundas documentation and installed SAML 2.0 and FAB, from:

https://www.dundas.com/support/learning/documentation/install-configure/installing-the-saml-2.0-protocol-aka-saml-p-extension

https://www.dundas.com/support/learning/documentation/install-configure/enabling-federated-authentication


but pretty much we're stumped beyond that, as far as configuring ADFS with the Relying Party Trusts, Claims Provider Trusts as far as integration with Dundas.

What we would like to achive as an end-goal is, an user from the IDP side, pass a "Member" id Claim request (or parameter) to the Dundas powered SP side.


I have servers for the ADFS & AD on both the SP and IDP side installed but again, configuration and testing as it relates to Dundas integration, eludes us.


Are there any SSO/SAML2.0 experts out there who have configured Dundas in the mix?

thanks much,
Cos



#2

Hi Cosmin,


When you set up the relying party trust in ADFS, you can use the URL from Dundas BI which provides the relying party (AKA "service provider") metadata. See the "Service Provider Metadata" section of the documentation for more details. If your ADFS server can't access the Dundas URL, then you'll have to just download the XML from that URL, and import it into ADFS as a file (instead of referencing the URL).


Once you've done that, you need to set up Claim Rules in ADFS for the new Relying Party Trust. At a minimum, you need to provide a mapping for the "Name ID" claim, which Dundas will (by default) treat as the user's unique account name.


Rob.

#3

thank you Rob, I will have a look at it.

#4

hi Rob, once configured, how does Dundas consume (receive) the claims? is it via $$ variables, is there something else (besides the manifest config) that needs to be done in order to recognize the claims by a Dundas app ?


thank you,

Cos



#5

Hi Cos,


As described in the "Enabling federated authentication" article, section 2.1 (Claim Types Mapping), Dundas BI extracts various pieces of data based on the claim types which have been set up to represent the corresponding types of information.


For SAML 2.0, the default claim types mappings are used, so you should follow those when setting up the claims in ADFS for the relying party, in the "Edit Claim Rules" dialog. If you are not happy with the default claim type mappings used by Dundas BI, you can use the manifest to override some or all of them, but this is optional.


If you append &debug=true to the authentication URL (see section 3.2 - FAB Configuration), then you'll eventually see a special page which shows you all the information involved, when you try and authenticate using federated authentication. It will show you things like:

- all the claims received from the identity provider (i.e. ADFS)

- how Dundas mapped the claims to the various properties (account name, email address, etc.)

- whether or not the information was able to be used to successfully create a session in Dundas BI.