Shibboleth Developers

["Scott Cantor" <>]

> Just another reason why SAML2 IdP Discovery is not for Shibboleth.

Within reason, Shibboleth should address traditional SAML deployment
scenarios as well as some we care more about. That's why it's important that
we implement the basic profile.

> I totally agree.  All I'm saying is that an (optional) cookie (NOT the
> common domain cookie) can provide this capability if the deployment
> wishes to exercise it.

Sure, but that cookie is not in the spec and doesn't need to be. We already
have this capability today and never needed to specify it, it's internal to
the prototype WAYF as it should be.

> But if the user chooses to remember it, can all the (SP, IdP) pairs be
> aggregated on a single web page so that they can change their mind
> later on?  (I think so...)

Yes, but they'll never see the page...this the paradox of remembering.

> My basic proposal is for two cookies, one that maintains IdP history
> and another that stores (SP, IdP) pairs.  Beyond that, everything else
> is implementation, yes.

No, the cookies themselves are also implementation details. They are never
exposed outside the WAYF, therefore they need not be in the spec.

> Nope.  I propose we remove the IdP from the cookie writing business
> altogether.  The history cookie is of limited usefulness (IMHO) so why
> not let the WAYF write it at the same time it redirects to the IdP? 

I don't disagree that in general the cookie set operation is less needed
here. But we have discussed this in the past because for some environments,
being able to "pre-provision" a preferred IdP is a useful thing to allow
for. I don't think it would be used in the flow of SSO the way the SAML
profile does it, no.

> Yes, authentication at the IdP may fail, but so what?  The user
> clearly intended it to succeed, so why not append the IdP providerId
> to the history cookie at the WAYF and be done with it?  Sure does
> simply the process.

We're not precluding that flow. It's what we do now in fact.

> There is nothing in the SAML2 IdP Discovery profile or the profile
> suggested in the Shib Architecture doc (which I like, btw :) that is a
> step towards (SP, IdP) pairs and a general GUI for modifying these
> pairs (which precludes the need for specialized clients).

Well, I don't know that I buy the pair thing in general, but regardless,
there is nothing in my proposal that prevents you from doing this, and going
further, what you propose is not something we need to specify here. It's not
a profile, it's an implementation.

Maybe it's the right one, I don't know. It definitely doesn't "solve" the
problem in the sense that you're implying. The problem is in general
unsolvable with current browsers. But it's a reasonable implementation of
the proposed profile and the WAYF's general function.

> I claim the history cookie can be handled by the WAYF but it MUST be
> in the spec for interoperability.  Likewise, the (SP, IdP) pairs are
> handled by the WAYF and they too MUST be in the spec (assuming we can
> figure out how to store this data in a reasonable way).

I disagree strongly. The cookie does not need to be in the spec because it
is not exposed outside of its own implementation. Nor are those pairs you're
proposing.

I think that in most respects with a few clarifications you posted earlier,
the two URL redirects I proposed will address the external interop
requirements needed for you to implement what you propose. I don't see why
you think the cookies somehow need further specification. Not every WAYF is
going to do what you propose or do it the same way.

-- Scott