Right now we're making every individual login flow decide to run the SetRPUI action to populate the context tree, and then we're duplicating that work in the interceptors.
The interceptors are actually using the default location in the tree, which is underneath the AuthenticationContext, so in theory they could be re-using it if it's done by the authentication flow up front.
The one hitch is possibly if they require that context to operate, and somebody flips the generic property off to avoid populating the information, but as a default nothing would break, and it could just be documented as required for those flows.
It's an oversight, but emphasizes how "do not use" initial-authn really should be treated now. I still have a TODO to go back and work over the documentation to make it clear that anything using it should be moved to the MFA feature.
It will be formally deprecated at some point, probably as soon as we make a decision on when we're going to bump the version to 4.0.
Philip Brusten
December 7, 2016 at 11:39 AM
Hi,
I discovered the RelyingPartyUIContext wasn't set anymore for InitialAuthentication. I guess you forgot to add SetRPUIInformation to initial-authn-flow.xml? Or was this done intentionally?
Could you please add it, because we want to display the RP-info during initial authN:
Right now we're making every individual login flow decide to run the SetRPUI action to populate the context tree, and then we're duplicating that work in the interceptors.
The interceptors are actually using the default location in the tree, which is underneath the AuthenticationContext, so in theory they could be re-using it if it's done by the authentication flow up front.
The one hitch is possibly if they require that context to operate, and somebody flips the generic property off to avoid populating the information, but as a default nothing would break, and it could just be documented as required for those flows.