Integrate 3rd party as one more Identity Provider

[Surinaidu Majji]

Thank you very much for your patience Peter.
We will go with the our own implementation to discover IDP (create two
static links, based on the selection of link we will forwarded the user to
respective IDP(3rd party or Shibboleth Idp) to get authenticated.). Based
on the third party protocol support we will send the authentication request
and get the response in the supported format.

Initially we tried to customize shib DS(EDS or CDS) for our own SP. So we
will stop investigating on this topic.

On Mon, May 4, 2015 at 9:42 PM, Peter Schober <peter.schober at univie.ac.at>
wrote:

> * 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
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150505/0f32d757/attachment-0001.html>