Alternatives to DS deployment

[Eric Goodman]

Thanks, 

Part of my confusion was the distinction between the DS and the EDS -- as in, I wasn't processing that there was one. 

The other part of my confusion was that none of the options I listed seemed like good alternatives (plausible maybe, but not good), so I couldn't figure out what alternatives I was actually being asked to consider. :)

So should that page of documentation be updated to refer to the EDS? (I'd offer to, but our IdP isn't releasing attributes to shibboleth.net at this point.)

--- Eric



-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Tuesday, June 18, 2013 1:40 PM
To: Shib Users
Subject: Re: Alternatives to DS deployment

On 6/18/13 4:21 PM, "Eric Goodman" <Eric.Goodman at ucop.edu> wrote:

>I¹m not sure I¹m fully grokking the advice here. Are these the kinds of 
>alternatives being suggested? Are there other common modes to consider?
>Or is something else implied here?

The embedded version is more recommended at this point, and is much less hassle to set up with a Shibboleth SP than standing up a whole Java app.

>* link to an existing WAYF/DS (such as InCommon¹s WAYF/Discovery 
>Service) rather than deploying locally

No, that is almost universally the wrong choice IMNSHO. That was a failed idea.

>* present a static list of idp-initiated SSO links

No, you don't need IdP initiated SSO.

>* present a static list of IdPs, then initiate actual authentication 
>requests by calling SAML libraries and redirecting the user directly in 
>your app (instead of having the SP do this)

No, you make the SP do it.

That's all the EDS is ultimately, a generator of automated links back into the SessionInitiator with the IdP specified. For a small number of IdPs, you can do that by hand.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net