| Panel | |
|---|---|
|
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.
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).
In general, no information (except the authenticated identifier) will be stored in the session.
Traffic Plugin Interface
TrafficController will introspect the requested URL and provide certain attributes to the Traffic Plugin:
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
public function login(?int $coId, ?int $enrollmentFlowId): string; public function logout(); |
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.