Sandor Molnar created KNOX-3548:
-----------------------------------
Summary: KnoxIDF: allow advertising the authorization and client
registration endpoints on other topologies
Key: KNOX-3548
URL: https://issues.apache.org/jira/browse/KNOX-3548
Project: Apache Knox
Issue Type: Improvement
Components: KnoxIDF
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 3.1.0
h3. Background
KnoxIDF serves its OAuth 2.0 / OIDC endpoints from every topology that contains
the KNOXIDF service. Deployments often split those endpoints across topologies,
because each one needs a different authentication provider:
* {{{}/authorize{}}}: browser-facing, authenticated with SSOCookieProvider
* {{/token}} and {{{}/userinfo{}}}: called by clients, authenticated with
JWTProvider (or anonymous for the authorization_code grant)
* {{{}/client/register{}}}: called by clients, authenticated with a bearer JWT
Each topology also serves the discovery documents
({{{}/.well-known/openid-configuration{}}} and
{{{}/.well-known/oauth-authorization-server{}}}). Those documents must point
clients at the topology that actually serves each endpoint.
The token endpoint already supports this. When the
{{token.exchange.topology.name}} service param is set,
{{AuthorizationServerMetadata.buildOAuthMetadata}} advertises
{{token_endpoint}} on that topology. It does this by literally substituting the
current topology name in the URL. {{DiscoveryResource}} applies the same
substitution to {{{}userinfo_endpoint{}}}.
h3. Problem
Two advertised endpoints have no equivalent setting. Both are always advertised
on the topology serving the discovery request:
{noformat}
metadata.put("authorization_endpoint", baseUrl +
AuthorizeResource.RESOURCE_PATH);
metadata.put("registration_endpoint", baseUrl +
RegistrationResource.RESOURCE_PATH + "/register");
{noformat}
*registration_endpoint.* Clients that use dynamic client registration (RFC
7591) find the endpoint through discovery. MCP clients are a typical example.
When discovery is served from an SSO topology, they are sent to a registration
endpoint that:
* is protected by SSOCookieProvider, so a programmatic POST without the SSO
cookie is redirected to the login page;
* may be blocked by the topology's authorization rules (e.g. PathAclsAuthz
restricting the topology to {{{}/authorize{}}});
* uses that topology's {{{}knoxidf.knox.token.ttl{}}}. A short TTL, which
suits SSO-issued tokens, also makes registered clients expire quickly.
Clients can't reach a dedicated registration topology through discovery; its
URL can only be handed to them out of band.
*authorization_endpoint.* This is the reverse of the token endpoint case.
Discovery served from the token topology advertises {{/authorize}} on the token
topology. That topology has no SSO provider, and is typically restricted to
{{/token}} and {{{}/userinfo{}}}. The token topology's discovery document is
therefore unusable for the authorization code flow.
h3. Proposed change
Add two KNOXIDF service params modelled on {{{}token.exchange.topology.name{}}}:
* {{{}client.registration.topology.name{}}}: the topology on which
{{registration_endpoint}} is advertised
* {{{}authorization.topology.name{}}}: the topology on which
{{authorization_endpoint}} is advertised
Example (on the SSO topology, {{{}oidc-sso{}}}):
{code:xml}
<service>
<role>KNOXIDF</role>
<param>
<name>token.exchange.topology.name</name>
<value>oidc-token</value>
</param>
<param>
<name>client.registration.topology.name</name>
<value>oidc-registration</value>
</param>
</service>
{code}
With this config, discovery served from {{oidc-sso}} would advertise:
{noformat}
"authorization_endpoint":
"https://<host>/gateway/oidc-sso/knoxidf/api/v1/authorize",
"token_endpoint":
"https://<host>/gateway/oidc-token/knoxidf/api/v1/token",
"registration_endpoint":
"https://<host>/gateway/oidc-registration/knoxidf/api/v1/client/register"
{noformat}
Setting {{authorization.topology.name=oidc-sso}} and
{{client.registration.topology.name=oidc-registration}} on {{oidc-token}} makes
its discovery document advertise the same endpoints.
h3. Acceptance criteria
* With a param set, both {{/.well-known/openid-configuration}} and
{{/.well-known/oauth-authorization-server}} (at both locations) advertise the
corresponding endpoint on the configured topology.
* With the params unset, the advertised {{authorization_endpoint}} and
{{registration_endpoint}} are identical to today's.
* The three settings are independent: {{{}token.exchange.topology.name{}}},
{{client.registration.topology.name}} and {{authorization.topology.name}} can
each be set without the others, and only the corresponding endpoint changes.
* Unit tests cover set and unset for each param, for both the OIDC and RFC
8414 metadata documents.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
