injecting and later consuming <saml:Subject>

[Scott Koranda]

> > Next please consider the Shibboleth IdP 3.2.x. Suppose that I
> > want to create a custom Password flow, modified from the
> > default flow, that is able to inspect the <AuthnRequest>,
> > determine if a <saml:Subject> exists, and then perform some
> > special actions if it does exist.
> 
> Actually, the Subject element is processed by the IdP now
> (e.g. consider queries) and I will have to look at the code
> and tell you exactly what it's doing during SSO. Point being
> you may not have to even look at the Subject itself to do
> something.
> 
> What I think it's doing is verifying that the canonical
> subject that gets produced during the login matches the
> reverse-mapped identity that the system obtains from the
> Subject, as that's what the SAML spec says to do. But I
> don't recall where it stashes the value. I think it may be
> creating a preliminary SubjectContext and notices that it's
> already there when it finalizes the authentication process
> and just checks for a match.
> 
> So if you care about the username more than the actual
> Subject XML, which would make sense, that's all done for you
> if you configure the Subject mapping behavior via the c14n
> layer in the IdP. You could have it do attribute resolution
> if you need it to to reverse map with LDAP or a database.

Thanks, but in this use case I want the IdP to inspect the 
subject before authentication.

At a higher level, what I want to do is pass in a subject and,
based on details of that subject, have the IdP actually create
the authentication account and upon success complete the SSO
flow and send a response/assertion.

Yes, I know, sounds crazy--it is a very specific use case.

The subject would contain a "token" (nonce) that the IdP would
use to call out to a "system of record" and verify that yes,
we want an account created for that identifier.

I guess I would use the c14n layer to later "clean up" the
subject (remove the token part).

So since I can invoke

((AuthnRequest) profileRequestContext.getInboundMessageContext().getMessage()).getSubject()

early in the flow, do the necessary confirmation/tests and
create the account if necessary, I should then be able to just
leverage a regular Password flow after that point.

I probably don't even need a modified Password flow--I can
just call Password as a sub-flow. Maybe. Have to think about
it more.

Thanks,

Scott K