OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [saml-dev] Indexed Endpoints


> But then it seemed to me that there was too much other state (tracking
> session participants for example) that would need to be tracked and that
> indexing the artifact endpoint only got you part of the way there.

There's a big difference between state that tends to last long enough that
propagation within 30 seconds or so is ok, and state that will need to
propagate almost instantly.

> Am I missing something here?  Was it assumed that all that other 
> state could be kept at a user session level?  And that distributing that
> session state could be pushed off to the application server or 
> container of your choice?

It's just a different kind of state. And yes, in some cases at least, things
can be pushed to the client or elsewhere. Logout isn't a requirement in all
scenarios, for example (the browser has this close option...;)

Consider transient IDs. You can easily encrypt the shared state into the
handle and enclose that in the NameID, and then use shared keys across hosts
to allow any server to recover the state. You can't do that with artifacts.

Let me put it this way...we think it's really, really useful, so if nobody
else makes use of it, it won't go to waste (it's easy to implement on the SP
side) and won't hurt anybody else by being there. ;-)

> In the SP case - I can see how the index is shorthand to reference an
> assertion consumer service URL.  I guess my question on that one is, why
> have more than one AssertionConsumerServiceURL in the first place?

First of all, it tells you which endpoint and binding to use in one small
field. The ProtocolBinding attribute is also mostly useless in light of it
(it goes hand in hand with the full URL). I'm probably going to split my
bindings up on separate endpoints to speed up recognition and dispatching,
so that's a use case for multiple endpoints right there. You have to have
separate metadata elements anyway, one for each binding, so there's no real
win to lumping them all at one location.

Secondly, vhosting. I might have a service that has different components of
the same service split across multiple vhosts.

If you're building gateways and doing proprietary SSO back to the actual
application, then it doesn't matter, everything might be multiplexed through
one endpoint. If you're using one standard SSO protocol, you have to
accommodate the realities of web deployment, and multiple endpoints is part
of that. There are various things of that flavor you can do within an
implementation if you can discriminate based on where the user comes in.

-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]