Passing ClientId as parameter while creating principal doesn't work

[fivetran-arunsuri]

Describe the bug

Hey Team,
I was trying to verify some of Polaris management API's. I found out that even though the documentation says we can pass clientId as param while creating the principal, it doesn't seems to be working fine

To Reproduce

1. Start the server and bootstrap with root credentials
2. create the token
3. Hit the http://localhost:8181/api/management/v1/principals API for generating the principal with body as below
   {
   "name": "principal-1",
   "clientId": "arman"
   }

Actual Behavior

It generates the principal as
{
"principal": {
"name": "principal-3",
"clientId": "9cc-blah-blah",
"properties": {},
"createTimestamp": 1750756252079,
"lastUpdateTimestamp": 1750756252079,
"entityVersion": 1
},
"credentials": {
"clientId": "9cc-bla-bha",
"clientSecret": "blah-blah"
}
}

Expected Behavior

It should ideally preserve the clientId we are passing from the body and only generate the clientSecret

Additional context

Also, Why are we not allowing users to set their own clientId and clientSecret while creating the principal?
I am looking for a solution like register principal with older credentials preserved? Can we do that like we do for the root credentials?

System information

No response

[eric-maynard]

The spec notes clientId is output-only here:

        clientId:
          type: string
          description: The output-only OAuth clientId associated with this principal if applicable

I found out that even though the documentation says we can pass clientId as param while creating the principal

Where is this in the docs? Sounds like we may need to fix that -- thanks for finding this.

[fivetran-arunsuri]

@eric-maynard The swagger Request body for the given API looks like this, could be auto generated but we need to correct that right?

Also regarding my second question, I would like to know the feasibility of the following
Why are we not allowing users to set their own clientId and clientSecret while creating the principal?
I am looking for a solution like register principal with older credentials preserved? Can we do that like we do for the root credentials?

[fivetran-arunsuri]

@eric-maynard Any update on this question?

[fivetran-arunsuri]

Also regarding my second question, I would like to know the feasibility of the following
Why are we not allowing users to set their own clientId and clientSecret while creating the principal?
I am looking for a solution like register principal with older credentials preserved? Can we do that like we do for the root credentials?

@eric-maynard following up on my previous query?

[eric-maynard]

Hey @fivetran-arunsuri, sorry I missed your previous comment.

From the service POV, I'm not sure whether or not creating a principal with specific secret is something we want to support. At best, it's fair to say we don't have that feature today. Instead, you could achieve this either by creating the principal directly in the metastore or directly with an external IdP.

As for the example in the docs, I agree that's misleading. I think that's auto-generated by Swagger though, so I'm not sure of the easiest way to fix that.

edit: To be clear I'm not opposed to approaching this as a feature request; I don't personally have an opinion on that.

[dimas-b]

This feels like a discussion of how the Authorization side of Polaris works (handling Principals managed by Polaris).

The Client ID here basically refers to the Client Credentials flow (OAuth2).

RFC 6749 states that "The authorization server issues the registered client a client identifier". So, I'd say Polaris is within its role as an Authorization server in this case.

That said, @fivetran-arunsuri : could you give us a bit more details why you'd like to control client IDs?

Note that it is currently possible to set custom client IDs for the "root" user during boostrapping (see the bootstrap command from the admin tool).

[eric-maynard]

(aside: filed #1992 to improve the example linked above)

[fivetran-arunsuri]

@dimas-b @eric-maynard Thanks for the response.

We’re in the process of migrating our self-hosted Polaris service from version 0.9 (EclipseLink) to 1.0 (JDBC-based metastore) in order to take advantage of the latest features and improvements in Polaris.

As part of this migration, we already have existing users registered with specific client credentials. Rotating these credentials is not an option, as it would break downstream queries and integrations for our customers.

We were hoping to register principals using existing clientId and clientSecret values, but currently the createPrincipal API does not support this—it always generates random credentials and stores them after salting and hashing.

We’re requesting either:

• a new API that allows registering a principal with user-defined credentials, or
• support for this functionality in an existing principal registration API.

This capability would significantly simplify our migration process, ensuring compatibility with existing credentials across both Polaris versions. Manual copying of principals isn’t a viable alternative, as it wouldn’t preserve the hashed credentials consistently across versions.

I will also explore the option of passing these credentials manually—similar to how we handle it during bootstrap—but instead of using command-line input, we’d pass them in the request body.
Would love to hear your thoughts on this approach before making any changes or opening a PR.

[dimas-b]

@fivetran-arunsuri : Thanks for the detailed explanation. Your use case makes sense to me 👍

However, I'd think this kind of principal manipulation probably belongs to the Admin Tool.

The Admin Tool could offer a new command with CLI arguments or file inputs (JSON?).

Would that fit your workflows?