3rd party IdP

I’m researching implement SSO into our ASP.NET project and am unclear what would be required from a 3rd party IdP?
1. Would they need to purchase ComponentSpace as well?
2. Which example best demonstrates what they would have to do on their end?

There is no requirement for the 3rd party to use our product. As long as the identity provider is compliant with the SAML specification there shouldn’t be any issues.
I suggest taking a look at the SAML high-level API example identity provider and service provider projects.
You’ll find these included in the Visual Studio solution under the Examples\SSO\HighLevelAPI. There are web forms and MVC examples.
Sections 10.1 and 10.2 of our Developer Guide PDF describe how to build, deploy to localhost and run these examples.

Thank you!

You’re welcome.

[quote]
ComponentSpace - Tuesday, August 9, 2016
You're welcome.
[/quote]

Hi,

I have a similar scenario where we have a third party idP.
I am new to SAML, the high level Identity provider sample uses component space but we don't know what code the third party would use. Is there an example of how the third party can send a SAML response to SP (us) which we can read using component space library? Will they need the same certificate the Service provider example is using?

We include example identity provider and service provider projects as described in sections 10.1 and 10.2 of our Developer Guide PDF. We generally recommend to start with these as they require no configuration changes and are the quickest to get up and running. It’s a good exercise to see SAML SSO in action.
However, these examples also include configuration for SSO with a number of 3rd party providers and you’ll see this documented in the Developer Guide as well.
For example, we include configuration in the ExampleServiceProvider project’s saml.config for the following partner identity providers: ADFS, Azure AD, Okta, Salesforce, Shibboleth and WSO2.
Our product is not limited to these 3rd party providers and works with all the major SAML offerings.
The first step to get SSO working with the IdP is to exchange configuration information.
The IdP needs to know information about your SP (eg the assertion consumer service URL which is where it will send the SAML response) and your SP needs to know information about the IdP (eg the IdP’s certificate so you can verify the XML signature on the SAML response or assertion so you can confirm that the IdP is the sender and the XML hasn’t been altered).
The IdP may supply you with their SAML metadata (an XML file) or may simply provide configuration information in an ad hoc manner.
Either way, the saml.config file (either for the ExampleServiceProvider, if that’s what you are initially testing with, or your application) will need to be updated to include a entry configured using the information supplied by the IdP.
Similarly, you will need to supply your configuration to the IdP either as SAML metadata or in an ad hoc manner. If using SAML metadata, this can be generated from your saml.config file using the ExportMetadata console application project that we ship.
Once configuration has been setup at the IdP and your SP you are ready to test.
Let us know if you need any assistance.
You’re welcome to email us if you prefer with specific information about your setup and the partner IdP.