Background
Registry v4 login operates by redirecting to a special URL outside of the Cake application that triggers web server authentication, which is typically implemented using something like mod_auth_shib or mod_auth_oidc. Upon successful authentication, the browser is redirected back to the Cake application, which consumes the authenticated identifier ($REMOTE_USER) and sets various attributes in the user session. Logout operates via a similar redirect.
This mechanism is limited in that it is not possible to support certain capabilities, such as IdP hinting. Furthermore, data stored in the session can become stale, requiring a user logout/login to receive newly granted privileges.
Use Cases
CO-Specific Discovery
Potentially leveraging data managed by another plugin (CO-2268), the discovery service presented to a user should offer options based on the IdPs actually registered within the CO.
Enrollment Flow-Specific Discovery
Although the configuration of such a capability (ie: specifying which IdPs are acceptable for which Enrollment Flow) is outside of the scope of this infrastructure, it should be possible for Traffic Plugins to consume this information and provide a hint to the IdPs based on which Enrollment Flow is being requested.
Login Event Update of Attributes
Registry v4 offers a Sync on Login capability to refresh Org Identity Source related attributes during a login event. This capability would be reimplemented as a Traffic Plugin.
Approach
Registry PE already has a new TrafficController, which handles mapping the authenticated identifier to a COmanage identity. (The initial authentication redirect request is handled by RegistryAuthComponent.) TrafficController will become a Pluggable Model, supporting a new traffic plugin type (more below). An instantiated Traffic Plugin will be referred to as an Authentication Detour.
In general, no information (except the authenticated identifier) will be stored in the session.
Traffic Plugin Interface
The various use cases identified so far have somewhat different requirements for the plugin interface, in terms of where plugins need to operate. For example, updating attributes on login simply needs to operate as a post-login callback, where as providing hints to an IdP might need to replace the entire authentication operation.
TrafficController will introspect the requested URL and provide certain attributes to the Traffic Plugin:
- CO ID, if known
- CO Enrollment Flow ID, if known
// Functions to be run before the actual login. Plugins can interrupt the login sequence // here (but in general shouldn't). Multiple Authentication Detours can be called for prelogin. public function prelogin(?int $coId, ?int $enrollmentFlowId): bool; // This call will replace the native authentication code. Only one plugin can be called for login. public function login(?int $coId, ?int $enrollmentFlowId): string; // Functions to be run after the actual login. Multiple Authentication Detours can be called // for post login, but the login sequence can no longer be interrupted. public function postlogin(string $username, ?int $coId, ?int $enrollmentFlowId); // Functions to be called on logout. Mulitple Authentication Detours can be called here as well. public function logout(string $username);
Additional Requirements
- Because authentication is configured at the server level, this Plugin infrastructure will use a platform-wide configuration, and will be managed only via the COmanage CO.
- Any implementation must allow a user to switch to a second CO after logging into a first. It is acceptable if this triggers a new authentication request.
Data Filters
It may be desirable to add a Data Filter-like capability to Traffic Plugins, though it's not currently clear where this data would be consumed and how it would be made available in those contexts. Use cases could include further munging attributes provided by the IdP. This topic requires further discussion.