getPrincipals() typing

[Cantor, Scott]

On 8/31/16, 10:05 PM, "dev on behalf of Klingenstein, Nate" <dev-bounces at shibboleth.net on behalf of nklingenstein at calstate.edu> wrote:

> I think that actually makes precise sense now, not just the fact but also the reason.  How
> you get served is calculated relative to where you entered.  The client is implicitly
> tracking where it came in using that.

The *server* is, not the client. The client sends cookies and URL parameters that allow the server to determine what the state of the flow execution is. Which one, and at what point in the flow/subflow sequence it stopped, and how to resume from that point.

> At least 4 different persistence mechanisms following at least 3 different persistence
> models -- HTTP requests, URLs/parameters, cookies, HTML 5 -- is where it got gross fast.
> They didn't choose to use cookies or local storage, and I'm sure there
> are reasons, whether dumb client or efficiency.

It is all cookies (that's how Java sessions are tracked) and then a URL parameter that identifies the multiplexed conversation / flow execution within a given session. That's how it fixes the tabs problem, the URL contains the additional state token to distinguish one from another.

JSESSIONID Cookie -> identifies the Java session
flowExecutionKey Parameter -> identifies a key to a table inside the Java session that stores the flow conversation state, so it can lookup the execution and then the state to resume from
    
> Neither the /you/are nor the flowExecutionKey is meaningful in isolation, and from the
> application's POV, it's all in quasi-isolation.  These queries just show up.

That's true. It's isolated implicitly by the JSESSIONID. That *plus* the parameter is how you know which piece of state on the server is the right state.

Which reminds me that I know for a fact JSESSIONID isn't address bound, and I was going to look at binding the address into our context tree so we can block the security attacks that seem to be beyond the ability of the containers to bother dealing with.

> This is the long story when I said "state is confusing".  I just have to think of the
> entire "/idp/you/are?flowExecutionKey=here" as the accessed resource and then start
> tracing from that point, but I can't really expect to be able to trace that
> down to the actual state as a human.

There are no resources here. This isn't REST. There's a path to invoke a flow, and then a parameter to track the state of it if it goes back to the client in the middle of the flow.
    
> What assumptions can I make regarding the safety of the input to Webflow?

None, as in any web application. Inputs are the responsibility of the application to sanitize.

> I saw CDATA back in your 3.3 authentication examples, though.

My examples are scripts, ergo they use CADTA.

CDATA is a technique for embedding arbitrary text in XML without having to encode characters. It's just convenient for embedding scripts and other kinds of arbitrary text in an XML element, and we've always used it in any examples where scripts are used. There is no functional difference between a CDATA block and the same text rendered without CDATA if the XML-illegal characters are encoded.

We're never going to agree about the potential for this to be "easy" or that breaking things into more pieces in a distributed system is generally practical. There's always a line. We're not going to build in a mail server, but that doesn't mean authentication doesn't have to be fundamentally part of an IdP. It does.

-- Scott