Shibboleth Developers

["Scott Cantor" <>]

> If you compare the AssertionConsumerService/@Location in the SPConfig with
> the one in the Metadata, you see that the Metadata has a complete URL
while
> the SPConfig only has a suffix that is used to select the protocol.

I debated a while about whether it was wise to reuse the metadata element or
not, since the Location values weren't directly equal. I think the semantic
equivalence in purpose is sufficient to justify it.

> To build
> a full URL you have to add the schema, hostname, port, and context, then
add
> the pseudo-CGI from Sessions/@handlerURL, and then add @Location. In
general, > there is no obvious or reliable source for the server part.

Well, there is on each server a way to do this (or one I implemented if the
server didn't have one). In any case, one reason for doing it this way was
to avoid duplicating a bunch of information over and over, so that it has to
be changed in sync.

> The Resource Manager knows its own URL, but there is no reason to 
> believe that the AssertionConsumer is on the same schema or port, and may 
> not even be on the same host.

As I've said before, if the resource is on a different host (or port) from
the ACS, what you're doing is SSO. I didn't want to do a new SSO protocol in
the code. If people want to build a gateway by combining the SAML half with
a back-end half that is more "lightweight", this can be an orthogonal piece,
it seemed to me, and that would be more modular anyway.

I don't see the huge benefit to avoiding a round-trip when the browser
happens to cross vhost boundaries vs. the round trip you would make when you
cross phsyical host boundaries. If there's a real benefit there, then a SAML
gateway is probably the right solution anyway.

> For example, the RM may use http because the data is not
> sensitive enough to require encryption, but the AssertionConsumer would
run
> on an SSL port number. In Java, it is possible for either the  SP or the
RM
> to provide the context to which the Assertions are presented.

http vs https in and of themselves don't necessarily imply a different
cookie domain. It's a special case, if you don't specify the secure
attribute. That's why I didn't worry about it.

> I do not find that the duplication of elements, with varied semantics, has
> been helpful here. I am inclined in the Java SP to revert back to the
> original Metadata semantics and use a fully qualified URL for the
> AssertionConsumerService/@Location rather than a suffix. This 
> means I will ignore the Sessions/@handlerURL because it will be embedded.

The downside is it makes some vhosting configurations more complex, and the
configuration is more error prone because you have so many places where the
hostname is referenced. I think that's a disadvantage, but I guess it's less
of one if you have some tools to assist at some point.

Anyway, the mismatch was intentional because of the duplication of data
otherwise.

> More broadly, I think we need to take a long term view of Session protocol
> selection. The IdP and SP may be at different levels and reflect different
> capabilities, especially when one or the other is foreign code. Rather
than
> putting in hard coded options (the force-push IdP option, or the
> default="yes", it makes sense for some code, probably duplicated at both
> ends and maybe even in the WAYF as well, to compare the Meatadata of the
two
> Entities and choose an optimal protocol from the ones available. Attribute
> Push seems better if both support it. If not, then Artifact, if it is
> supported, might be marginally better than POST followed by the AA query.
> Maybe this is an Entity or Federation decision. 

Well, we've started looking at this a little bit, but it is definitely
metadata driven. The problem is there is no metadata about "attribute push"
right now explicitly. The reason we have it is that old Shibboleth code
doesn't support it, so implicitly any given SAML SP might or might not. The
flag is intended to help tune this behavior to react to compatibility issues
until things are more uniform.

We also felt it was a policy decision by the IdP. I may refuse to push using
POST, since the data would be in the clear in the client. So it's less of a
"profile" choice, and more of a behavioral option for the deployer to
consider.

But the 1.3 SP's SessionInitiator code is metadata driven, for example. It
can be told which ACS endpoint to tell the IdP to use, along with the IdP's
name. With that information, it can use metadata to find out what protocols
it supports and where and the SP can prioritize. Only problem being we only
have the Shib request protocol implemented now, so the choices are limited.
;-)

I do favor SAML 1.1 over SAML 1.0, though, for example.

So this is all pretty much understood that we need to rethink it a bit for
2.0 and make sure it all hangs together properly.

WAYFs are a special case, but certainly an unsigned request could be
protocol-translated by a WAYF (Shib to SAML 2.0, or vice versa). We're also
looking in the SAML TC at an extension for 2.0 to profile how a portal or
WAYF could request something on behalf of an SP without playing games.

> This produces a proposal, just kicked out so you get a better idea of my
> thinking, that the shireURL sent to the IdP might end in
> ".../Shibboleth.sso/*". This tells the IdP to use any of the URLs
configured
> as AssertionConsumerService/@Location in the Metadata for the SP Entity
that
> begin with a prefix specified in the shireURL parameter of the query
string.

We really can't. We're not changing the old profile anymore (right?), and
this wouldn't be legal now. It's also not possible to do this in SAML 2.0,
as a specific ACS must be identified by location or index, or the default is
used.

> of making an optimal decision. If this were accepted, then it would
reverse
> my previous model in that the md:AssertionConsumerService in SPConfig
would
> be ignore (and would no longer serve a purpose) because the
> Sessions/@handlerURL would be all that is required. 

It's not consistent with how Shib and SAML are defined at the moment. Note
also that I have distinct locations for Artifact vs. POST because I thought
going forward I'd be better able to efficiently implement multiple bindings
and profiles in 2.0. But if you put them at one location, then you could
have a simpler configuration, I can't deny that. I didn't see any obvious
way to pursue that model going forward so I went ahead and just defined a
structure for mapping it out separately.

The absolute/relative URL question is more of an implementation choice. I
could force SP deployers to do the same thing you're proposing if we wanted
to be consistent, although now we have software in the field that uses
relative, and I'd have to add code to support absolute and change the way I
determine how to dispatch to the handler functions.

In my case, I didn't implement a way for a "vhost" to have ACS endpoints on
another vhost, so the factoring was already in place to paramterize the
hostname in most cases (or in most cases the scheme/host/port), and in all
cases within a Sessions element, all the hostnames had to be the same.

-- Scott