RE: [saml-dev] Indexed Endpoints

["Brian Campbell" <bcampbell@pingidentity.com>]

In the artifact case, my first thought was that the artifact receiver
endpoint had been indexed for just the reason you mention - to simplify
load balanced deployments by not requiring some sort of shared storage.
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.  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?

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?  I
know it's a carryover from Liberty but I never knew the intent of it in
that spec either.

Thx,
Brian

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Monday, April 04, 2005 11:00 AM
To: Brian Campbell; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] Indexed Endpoints

> Can anyone enlighten me on what the intent of indexed 
> endpoints was?  Honestly, I just don't see how or why it 
> would be used.

Which ones? There are a couple of different occurrences, for different
reasons.

In the artifact case, it's the only thing that makes the artifact
binding
usable without a ridiculous amount of work (reason number one I hated
artifacts in 1.1). Without it, even the simplest implementation needs
efficient, writable, clustered storage to load balance the IdP. With it,
you
can issue artifacts that point directly back at the endpoint with the
in-memory storage of the protocol message.

In the SP case, as it was in ID-FF, it's to enable compact referencing
of
the consumer service to use in the AuthnRequest without having to put
the
whole URL in the request. In fact, the AssertionConsumerServiceURL
attribute
is mostly worthless since you need to check metadata in most cases
anyway,
and I should have just removed it altogether.

-- Scott