Shibboleth 2.4.3 SAML2 and WAYF

[Law, Bob]

Our WAYF simply lists the federations and when selected the entities
that belong to the federation.  It then redirects the browser to the
entity for login.

If the embedded DS does not support saml1 then we won't be able to use
it.  Doesn't the SSO tag allow both saml1 and saml2?  Is it just the
code in shibboleth that won't send out saml1?

Robert Law
Software Engineer
Wolters Kluwer Health Medical Research
801.304.3012 tel
Robert.Law at wolterskluwer.com
www.ovid.com


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
On Behalf Of Cantor, Scott
Sent: Friday, January 13, 2012 1:18 PM
To: users at shibboleth.net
Subject: Re: Shibboleth 2.4.3 SAML2 and WAYF

On 1/13/12 3:10 PM, "Law, Bob" <Robert.Law at wolterskluwer.com> wrote:

>Will do.  I guess I will tell my coworkers that we need to do an
>entirely fresh install of 2.4.3.  Does the embedded DS eliminate the
>need for WAYF?

I don't know specifically what you mean by "WAYF" in the abstract. The
concept of a WAYF was a discovery interface and the original protocol
was
a relay for old requests to Shibboleth 1.x IdPs. The DS concept is a
modern replacement that speaks a different protocol and handles any SSO
protocol between the SP and IdP. Most DS software implements both the
old
and new discovery protocols for compatibility. The EDS doesn't because
it
assumes an SP that speaks the new one so there's no reason to do both.

Any given WAYF is/was a specific deployment that addresses some service
and/or community in some specific way. Replacing that means addressing
whatever that community's needs were in the UI and so forth, apart from
just substituting one protocol for another.

Most WAYFs were also hosted centrally by federations. The EDS is
designed
to assist SPs that host their own with more UI integration than a stand
alone DS application tends to support.

-- Scott

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