Integration of Discovery Service

[Rod Widdowson]

Let's see if I understand this:

- You have a custom-built SP which speaks SAML.
- You have a Shibboleth IdP.
- You are about to introduce a different IdP ("SIICA") into the mix which speaks something else than SAML.  You are going to (or have) modified your SP to speak this "Something other than SAML".

This is thin end of the classic "discovery problem".

> We have got two IDP's and in future it may add one more.

To be honest with just two IdPs to deal with, either of the discovery services are going to be overkill - they are both targeted to scale to systems supporting thousands of IdPs where number and location of IdPs may change on a daily (or even hourly) basis.  My suggestion (but I encourage others to disagree) is that you write your own discovery page with two links on it.  One for your shibboleth IdP, and one for SIICA.   You can make such a page fit in with the rest of your SP's look and feel easily.  Job done.

This obviously has scalability issues and once you start thinking about more than 3 IdPs you should reconsider.

For the record:
> 
> 1) Embedded Discovery Service:
>       On studying about this DS, I found that, it is tightly coupled with the Shibboleth's SP. Am I correct?. 

Not at all.  It speaks the standard Discovery protocol.  All that is special is that the Shibboleth SP knows how to process SAML metadata to provide the JSON metadata that the EDS consumes.

If you decided you needed a discover service rather than a discover page you would need to deploy an EDS.

> Is it possible to integrate this DS into our Service provider which is not Shibboleth.

Yes.  To make the EDS work, you 'just' need to:
1) Implement the IdP Discovery Protocol (http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf).  Note that this protocol is ENTIRELY disconnected from SAML - it will do IdP discovery for any protocol
2) Implement a feed (which I guess could be static) for the JSON metadata that the EDS consumes/

> 2) Centralized Discovery Service:
>      If there are more IDP's then this is better. 

No.  Each scale similarly.

The CDS is better if:
- You have a need for non javascript browsers 
- You need a system which speaks the legacy and proprietary Shibboleth SAML1 IdP initiation protocol.
- You are a federation and need to provide a scalable (by SP number) back stop for those SPs who chose to not deploy an EDS.

> So, is it a better choice to use the Centralized Discovery service into our project?

No.  I see absolutely no reason for you to go down the CDS path.  If you were to, the integration would be the same as for the EDS, only in that case the feed would be SAML2 metadata (which again need have *NOTHING* to do with SAML being used to do the actual AuthN/SSP)


/Rod