Skip to Content.
Sympa Menu

shibboleth-dev - RE: comments: draft-mace-shibboleth-arch-conformance-01

Subject: Shibboleth Developers

List archive

RE: comments: draft-mace-shibboleth-arch-conformance-01


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Tom Scavo'" <>
  • Cc: "'Shibboleth Development'" <>
  • Subject: RE: comments: draft-mace-shibboleth-arch-conformance-01
  • Date: Wed, 10 Nov 2004 20:17:21 -0500
  • Organization: The Ohio State University

I think I see the problem...

> The profile specifies that the common domain cookie writing service is
> invoked after the principal is authenticated by the local authn
> service.

That's not what my copy says, but I don't recall if the text has changed
since CD2. Maybe that's the confusion. Somebody (I thought it was you)
commented on some aspect of this text, but anyway, what it says now is:

"After the identity provider authenticates a principal, it MAY set the
common domain cookie."

Nothing in there about "local authn service". The boundary between the IdP
and "local authn" is what's really out of scope. The entire box around the
SAML behavior and authentication is what really makes up the IdP.

> Now the authn event is out of scope and as far as I can tell
> the invocation of the cookie writing service is out of scope as well.
> That doesn't leave much for the IdP to "support", I'm afraid!

That's not my reading, and it's definitely not the actual fact. The IdP sets
the cookie after authentication and before responding to the SP. It's
certainly not done by the "local authn service" since it can't. That entity,
if it even exists, is legacy code that isn't SAML aware.

In practice, of course, SAML products other than Shibboleth all do the
authentication themselves because, well, it's easier to control logout that
way.

> Given what I know about typical authn services, I could imagine that
> the IdP might redirect to the local authn service with a parameter
> that targets the cookie writing service, something like this:
>
> https://idp.com/auth/controller?action=login&target=target

No, how would it have any hope of the local service supporting this profile?
Not realistic, I don't think.

> So after the authn event occurs, the cookie is updated, and the client
> ends up back at the SSO service so that the message flow can continue.

More like:

SP sends request
IdP either authenticates by itself or protects its endpoint with some other
authn service
IdP sets cookie
IdP responds to SP

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page