[
https://issues.apache.org/jira/browse/KNOX-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138534#comment-18138534
]
ASF subversion and git services commented on KNOX-3548:
-------------------------------------------------------
Commit 54fa132df75649cf246ad9f8b4ea66699178f05d in knox's branch
refs/heads/master from Sandor Molnar
[ https://gitbox.apache.org/repos/asf?p=knox.git;h=54fa132df ]
KNOX-3548: KnoxIDF: allow advertising the authorization and client registration
endpoints on other topologies (#1488)
> 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
> Priority: Major
> Fix For: 3.1.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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)
