Integrate 3rd party as one more Identity Provider

[Peter Schober]

* Surinaidu Majji <pioneer.suri at gmail.com> [2015-05-04 15:25]:
> > > That's why i am calling "Third Party" as an "IDP" which is similar to
> > > Shibboleth Idp. Is my assumption correct? Please correct me if i am
> > wrong.
> >
> > There should be no guesswork involved (so I won't guess).
> > Whether the third party deploys a SAML IDP or not (i.e., whether
> > they're able to send SAML response messages to SAML request messages)
> > is something you would ask them.
> >
>   - - We know the 3rd party will not support any SAML format.

So what do you expect from this forum/group/project then?
The authentication server does not speak SAML (so almost by definition
it's not Shibboleth software) and your SAML SP is not Shibboleth.

> >    - As per our current requirement we need to work with only 2 idp's, May
> be in the future it might be extended to one more.

I already told you, just create static URLs that will initiate SSO
with the right system, using the correct protocol for the selected
system.
Since your SP is not Shibboleth (and the other IDP is neither
Shibboleth not does it support SAML) there's nothing else to say in
this forum.

> I went through all the discovery services provided by shibboleth, I have
> the following observations.

Forget the Shibboleth Discovery Services (CDS or EDS), or any other
Discover Service product. It's overkill for 2 IDPs, and it would
implement the SAML Discovery Service Protocol, which your SP probably
doesn't even support.

> > initiating the desired protocol exchange via whatever method your
> > SP (or IDPs) support.
>
> What is meant by protocol exchange here?

Like most other protocols, the SAML protocol consists of request and
response messages. For an SP sending request messages and accepting
(and processing) reponse messages could be called "protocol exchange".

"Initiating" this was meant to mean at some point your application or
SAML SP implemention will need to initiate SSO with the SAML IDP, in
order to recieve back trusted attributes, in order to grant or deny
access to the subject based on those attributes.
(If you don't do any of this why would you use SAML.)

What you want is to give subjects a choice of their authentication
system: in one case your Shib IDP, in the other case something
proprietary (it seems). So what you need to do is to construct a SAML
authentication request from your application (or SAML SP
implementation) to the SAML IDP.
And whatever else for the other system, about we we don't know
anything (and don't need to care on this list, as we've established
that neither the SP nor the IDP are Shibboleth).
-peter