Hey all,
I was hoping to get some advice on using ComponentSpace on a prototype project for a client, maybe some pushing towards the correct implementation, or some definite, “don’t do that, you fool”. My understanding of SAML is rapidly growing but I lack some missing bits I hope can be filled in on.
The process flow for the project is as follows (ASP.NET core 3.1)
- User is added to our database (usual details including username and password).
- User logs into the site and standard ASP.NET Core Identify Claims are set for Given Name, Family Name, E-Mail, GUID etc. The login process is our custom code, should this be replaced the examples given for IdP, or are we OK to carry on like this?
- User is presented with a range of “vendors” on a dashboard page, each vendor is a Service Provider that requires an assertion & metadata in their own format, with the usual SAML Response signed (our .pfx) and the assertion encrypted with the SP public key.
- User clicks the vendor logo and the ComponentSpace magic does it job and sends the assertion to the SP and if all is valid on the SP side, the user is silently logged into the SP’s website and is redirected to their dashboard.
- The unique identifier for each user is their e-mail address which is registered as the same across all SPs.
So, I guess this makes our website the IdP as the user is validating against our database and identity service, while we push the user via the assertion post to the various SP’s once they click a vendor logo. There could be 1 vendor or there could be 10, it depends what vendors our user has been signed up to.
Do we still need to use all the IdP type wire-up discussed about in the ComponentSpace examples (since we’re doing our own identity verification), or can we just post a different assertion to each SP? Are there any examples to show this (I’m still in the R&D phase atm so I’m hedging my bets on someone making something click for me)?
Thanks.
You can use your existing login process. The application is responsible for authenticating the user. We don’t place any restrictions on this. Our examples use Microsoft Identity as per the standard Visual Studio project template but any login process is fine.
The flow you describe is IdP-initiated SSO with your site acting as the IdP.
You mentioned multi-tenant service providers. Our multi-tenancy support allows each tenant to act as its own separate IdP with its own separate SAML configuration. This is useful for SaaS deployments. If your application is acting as an IdP and you’re supporting multiple partner SPs, you don’t need our multi-tenancy support as this is supported in a single SAML configuration. More information about this may be found in our Configuration Guide.
https://www.componentspace.com/Forums/8234/Configuration-Guide
For IdP-initiated SSO, the only SAML API call you need to make is _samlIdentityProvider.InitiateSsoAsync. The ExampleIdentityProvider demonstrates a number of different SAML flows including IdP-initiated SSO. I suggest taking a look at the ExampleIdentityProvider’s SamlController.InitiateSingleSignOn method for an example of calling this API. The partnerName parameter specifies which partner SP in your SAML configuration to initiate SSO to. The userName and attributes are the user identity information to include in the SAML assertion. In your case it sounds like you would specify the user’s email address for the userName parameter. The optional relayState parameter specifies a URL the SP should redirect to once SSO completes. This supports deep linking into the SP.
I hope that helps. Feel free to ask any follow up questions you might have.
[quote]ComponentSpace - 6/23/2021
You can use your existing login process. The application is responsible for authenticating the user. We don't place any restrictions on this. Our examples use Microsoft Identity as per the standard Visual Studio project template but any login process is fine.
The flow you describe is IdP-initiated SSO with your site acting as the IdP.
You mentioned multi-tenant service providers. Our multi-tenancy support allows each tenant to act as its own separate IdP with its own separate SAML configuration. This is useful for SaaS deployments. If your application is acting as an IdP and you're supporting multiple partner SPs, you don't need our multi-tenancy support as this is supported in a single SAML configuration. More information about this may be found in our Configuration Guide.
https://www.componentspace.com/Forums/8234/Configuration-GuideFor IdP-initiated SSO, the only SAML API call you need to make is _samlIdentityProvider.InitiateSsoAsync. The ExampleIdentityProvider demonstrates a number of different SAML flows including IdP-initiated SSO. I suggest taking a look at the ExampleIdentityProvider's SamlController.InitiateSingleSignOn method for an example of calling this API. The partnerName parameter specifies which partner SP in your SAML configuration to initiate SSO to. The userName and attributes are the user identity information to include in the SAML assertion. In your case it sounds like you would specify the user's email address for the userName parameter. The optional relayState parameter specifies a URL the SP should redirect to once SSO completes. This supports deep linking into the SP.
I hope that helps. Feel free to ask any follow up questions you might have.
Thanks for response,
This is pretty much the same conclusion we've come to today as well, so thanks for confirming that! Very reassuring for us at this early stage.
As you suggested, we've already been using
_samlIdentityProvider.InitiateSsoAsync to make a call to a 3rd party SP who have set up a test account for us. We're definitely get passed all the steps locally our end to prep the assertion, do all the signing/encrypting, and posting the assertion, but we're failing to log in. Without another external SP to test with at the moment, we can't tell if this is an issue with them or us, so I guess we'll look at some other SPs we can test with tomorrow. Any suggestions greatly welcomed.
One comment we have picked up that our current SP has mentioned is that they don't support SP initiated SAML, seems they only want the assertion/SAML Response. Does this change any of the configuration or calls we make our end in a standard IdP Initiated SSO type project?
Thanks.
Most issues are related to configuration. I suggest double checking that your configuration for the partner service provider is correct. Assuming it is, you will need the SP to provide more information. They will need to check their logs etc.
If the SP doesn’t support SP-initiated SSO and only supports IdP-initiated SSO, that’s perfectly fine. What you’re doing by calling _samlIdentityProvider.InitiateSsoAsync is all you need to do.
If SSO with the SP is not working and you need our assistance, I suggest enabling SAML trace and sending the generated log file as an email attachment to support@componentspace.com.
https://www.componentspace.com/Forums/7936/Enabling-SAML-Trace
Also include a screenshot of the browser and any information provided by the SP.
Thanks.