custom auth flow fails subject canonicalization and indicates deeper issue

[Scott Koranda]

Hi,

I am using IdP version 3.2.1.

I have built a custom authentication flow. After starting the
IdP the flow works as I expect. Using a specific credential I
can authenticate and eventually an assertion is sent to the
SP.

When the flow is invoked a second time using a different
credential the custom subject canonicalization fails.

I built my custom subject canonicalization class by extending
AbstractSubjectCanonicalizationAction and I modeled it after
SimpleSubjectCanonicalization. I basically changed
'UsernamePrincipal' to 'MyPrincipal'. The logic is identical.

The subject canonicalization fails in the call to
doPreExecute(). Specifically the evaluation of

embeddedPredicate.apply(profileRequestContext, c14nContext, true)

returns false and so doPreExecute() returns fals.

The embeddedPredicate or ActivationCondition is also the same
as that for the SimpleSubjectCanonicalization. It uses the
c14nContext to find the subject and then the principals, in
this case instances of MyPrincipal.

Specifically the test to see if multiple MyPrincipal instances
are present because...there are multiple instances. I logged
them and much to my surprise they are the MyPrincipal
instances resulting from the two different invocations of the
flow using completely different credentials (and browsers for
that matter).

I am obviously missing something fundamental if two
invocations of the flow by different users result in two
instances of MyPrincipal ending up somehow co-mingled.

My class ValidateMyCredential is modeled on
ValidateUsernamePasswordAgainstLDAP. After validation my code,
in doExecute(), calls

buildAuthenticationResult(profileRequestContext, authenticationContext);
ActionSupport.buildProceedEvent(profileRequestContext);

I also have

@Override
@Nonnull protected Subject populateSubject(@Nonnull final Subject subject) {
    subject.getPrincipals().add(new MyPrincipal(myContext.getIdentity));
    return subject;
}

I appreciate any input you have, and my apologies for this
relatively esoteric note.

Thanks,

Scott K