[#11409] fix(idp): Validate incompatible simple mode at startup - #11497
Conversation
…ation enabled Reject incompatible Simple + authorization configuration when the built-in IdP plugin starts, including the default gravitino.authenticators value. Co-authored-by: Cursor <cursoragent@cursor.com>
|
@roryqi Could you please review this PR for me? Thank you. |
…onfiguration Log the configuration error and call System.exit(1) from IdpConfigurationValidator when built-in IdP is enabled with Simple authentication and authorization. Co-authored-by: Cursor <cursoragent@cursor.com>
| import org.slf4j.LoggerFactory; | ||
|
|
||
| /** Validates server configuration before the built-in IdP plugin starts. */ | ||
| public final class IdpConfigurationValidator { |
There was a problem hiding this comment.
The logic seems simple. We don't need this class.
There was a problem hiding this comment.
Got this class has been removed.
| * @param config The server configuration. | ||
| */ | ||
| public static void validate(Config config) { | ||
| if (!config.get(Configs.ENABLE_AUTHORIZATION)) { |
There was a problem hiding this comment.
Why do we need this logic? Authentication is different from authorization.
There was a problem hiding this comment.
Only when "Simple + authorization" is used will the basic header be sent. If only "simple" is configured but authorization is not enabled, the "basic" header will not be sent, it is still usable.
There was a problem hiding this comment.
No, it will send basic header only if we use the simple mode.
There was a problem hiding this comment.
Only when "Simple + authorization" is used and user login graivitno through WEB-UI, front end will send the basic header.
If only "simple" is configured but authorization is not enabled, front end will not send the basic header.
Only front end send the basic header ,the IDP's filter to perform the verification, resulting in an error.
There was a problem hiding this comment.
Why does front behavior decide backend behavior?
There was a problem hiding this comment.
It is not the front end that determines the behavior of the back end.
No matter which mode enables authentication, it is necessary to inform the backend which user invoked the interface. In the simple mode, if authentication is enabled, it will use the same format as the basic mode and send a header containing the basic information. This will cause the bug to occur.
There was a problem hiding this comment.
Authorization isn't different from authentication.
Basic is an authentication mode. We can use authentication when we don't enable authorization.
I will suggest removing the authorization check here.
… IdpRESTFeature Remove the standalone validator class per review feedback and keep the same fail-fast behavior with tests moved to TestIdpRESTFeature. Co-authored-by: Cursor <cursoragent@cursor.com>
Code Coverage Report
Files
|
… is enabled Drop the authorization.enable guard so Simple and built-in IdP Basic cannot be combined regardless of authorization settings, per review feedback. Co-authored-by: Cursor <cursoragent@cursor.com>
…atibility Configure IdpRESTApiIT with OAuth so the server starts under the new validation, and document that built-in IdP cannot be used with simple. Co-authored-by: Cursor <cursoragent@cursor.com>
| public class IdpRESTApiIT extends BaseIT { | ||
|
|
||
| /** RSA public key used only to satisfy OAuth authenticator initialization in this IT. */ | ||
| private static final String OAUTH_PUBLIC_SIGN_KEY = |
Replace the hard-coded RSA public key constant with runtime generation. Co-authored-by: Cursor <cursoragent@cursor.com>
…idation Resolve idp.yaml description conflict by keeping the Simple auth incompatibility note from this PR. Co-authored-by: Cursor <cursoragent@cursor.com>
What changes were proposed in this pull request?
IdpConfigurationValidatorinorg.apache.gravitino.idp.configto validate server configuration before the built-in IdP plugin starts.gravitino.authorization.enable=trueandgravitino.authenticatorsincludessimple(including the default value).IdpRESTFeature.configure()before IdP registers HTTP Basic authentication.simple, default authenticators, and compatible OAuth configuration.Why are the changes needed?
Enabling built-in IdP (
gravitino.server.rest.extensionPackages = org.apache.gravitino.idp.web.rest.feature) together with Simple authentication and authorization leads to broken Web UI login: the IdP plugin injects HTTP Basic authentication ahead of Simple, while Web v2 sends username-only Basic credentials.This change fails fast at startup with a clear error instead of leaving operators with a running server and a non-functional UI.
Fix: #11409
Does this PR introduce any user-facing change?
IllegalStateExceptionwhen built-in IdP is enabled with authorization and Simple authentication (explicit or default).simplefromgravitino.authenticatorsor disablegravitino.authorization.enable.How was this patch tested?
./gradlew spotlessApply./gradlew :plugins:idp-basic:test -PskipITs -PskipDockerTests=true --tests org.apache.gravitino.idp.config.TestIdpConfigurationValidator