getPrincipals() typing

[Cantor, Scott]

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

> Yeah, that was what I was after.  There are no semantics or constraints anywhere.

There are semantics and constraints in many places, just not in those classes or interfaces. A UsernamePrincipal is exactly what it says it is. A Principal is not always a UsernamePrincipal, but a UsernamePrincipal is one type of Principal.

That's why the Subject collections are typed. If you want a specific type of Principal, you just specify the type you care about and you ignore the rest.

> I'm still mystified that I can call the Password flow as a subflow without modification.

You should be, that was an incredibly hard feat of engineering that I didn't even think would work until I tried it and it did.

> What are the flow execution keys even relative to?

The flow executing is the flow definition assigned to the location you start the browser at. Probably one of the SAML.SSO flows. There are separate flows for each binding. Everything else is a subflow called by that flow and the execution key is the same for the life of the main flow. Any subflows start and end inside that flow but they don't end the flow at the top, they just end with the result state they ended with and the calling flow takes over.

You should have no need to worry about any of the webflow execution machinery, that's all automatic. The only thing you have to do is use the flowExecutionUrl inside any forms or redirects and the rest is all done for you.

> This is the whole "where is the entrance" and "where is the exit" stuff.  Tom Zeller
> guessed what I meant.
>    
>    There basically is no entrance nor exit.  There's basically no state anywhere.

Other than that being incorrect, I don't know what to tell you. There's state all over the place like with any complex application, and the places where subflows can get called is entirely proscribed.

> I don't know definitively that it was null.  It wasn't barfing, and it did barf if I
> didn't set a static type for UsernamePassword (e.g. trying to literally use
> "UsernamePassword" or "UsernamePassword.class" without a T).

Specifying classes is what the T() syntax does in Spring. Without that, you just have an error. I'm just saying that not specifying the Principal type at all is pretty much always incorrect. It's fine if you're trying to iterate over every Principal, but randomly grabbing one will not give you anything predictable.

> That development="true"
> to try to reload the flows is pretty much... not awesome.  If I didn't have to spend a
> minute and a half between tests, this wouldn't be Wednesday.

I have never used it and don't think it can possibly work, so that doesn't surprise me.

-- Scott