Shibboleth Developers

[Scott Cantor <>]

> I'd kinda like to see proposed arch doc text before modifying 
> on-the-wire formats.

That's fine, after further rumination, while it's still useful to do,
it's not as useful as it is here at OSU, because I have other properties
in the system that enable me to short circuit old, replayed "HS"
requests. Without a unique ID in the HS request format, it's not as
useful to just have a timestamp.

So for now, let's leave it at this, I fixed the problem and if you hit
the Back button, you're gonna get logged in again. Any errors that
complain about replay or expired assertions at the SHIRE are not going
to be from hitting the Back button.

> The request generator puts in the time the request is 
> generated, in what format, with what resolution?  How is the 
> HS (or whatever we decide to call it other than HS) supposed 
> to process this?

I use standard 32-bit time_t values, which Java can handle pretty easily
as well, and are easy integer values to deal with. There is no advantage
to finer resolution here.

> This is only an indication of clock skew at the target?  

No, it's a timestamp that enables a component to recognize a request
that's older than the allowable time skew between the component
generating and the component receiving the request.

That allowable skew would need to be defined by policy, since normally
the allowable skew is enforced in the other direction.

I know some people think eliminating/restricting clock skew is a huge
problem, and a complication. I don't understand that viewpoint, maybe
because I'm used to DCE/Kerberos. But it seems to suggest it be
optional, in any case.

> Seems to me this doesn't apply at all in the case of the 
> local-nav site, or of the redirecting WAYF, both of which 
> would have their own clocks separate from the target.

I thought of that. The WAYF can attach its own timestamp (I think you're
misunderstanding the purpose, it's to stamp the final request to the HS,
not the original request from the target).

The local-nav case could be handled by having the HS redirect to itelf
and add the timestamp to the URL.

> If it's supposed to help fix the multiple-POST problem I guess I 
> don't see how it does that.

An obviously old request can be ignored and instead a special page
generated with a message explaining that's it's a previous reuest that
can be ignored, and also with JavaScript that sends the user back in the
browser's history list to whatever's prior to the HS request.

That makes the Back button "skip over" the login page in the history
list, to whatever was being shown before they triggered authentication.
Obviously, this is more useful in the target-first case where you
seamlessly go from insecure->secure content, which I confess is how we
do things.

> If we're modifying the request format I have a whole pile of 
> candidate params, basically everything pubcookie has now or 
> might have shortly: login-policy, don't-use-SSO, 
> don't-prompt-user, etc.  The more general question perhaps is 
> extensibility of this format and registration of these param 
> types and values.

I agree (and I have similar stuff I use for don't-use-SSO and other
things myself). Liberty, of course, uses an ugly XML->URL format to
encode a real XML request on the URL, which I'm not too fond of, but it
is one approach.

In any case, what's going to happen is that I will abide by the wishes
of the architecture team in terms of timing on all this. I need some of
these features in order to bring Shib up to feature par with other SSO
systems (as you've noted in the past). They will happen locally at OSU
while awaiting standardization in the broader community, or as part of
Shib as time and the team permits.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--