OPENAM-16522 addressed a number of important issues but its implementation also broke a number important use cases the field is often asked to implement/show.
It used to be that nodes identified the main subject of their activity by resolving the identity from the value of sharedState.get("username"). This allowed a tree to operate on any number of identities during execution. E.g. it was possible to first validate the identify of a helpdesk user (collect username and password, then datastore decision to validate credentials) and then change context to a different user by either collecting another username (use case here could be impersonation) or manipulate shared state directly and then request a 2nd factor from the user to be impersonated (popular demo request is a push to the impersonatee before allowing the impersonator to proceed).
Nothing in the concept of the use of a universalId should impact those use cases, but the current implementation of the fix for
OPENAM-16522 only sets the universalId ONCE and never updates it. So which ever username is collected first determines who the subject of the tree is.
That is a big limitation and constrains the usefulness of trees for use cases other than straight authentication, like:
- Peer authentication
- Any non-authentication flows that act on more than one subject
It appears that the issue was introduced by this commit: