[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]