[pdm-devel] [PATCH datacenter-manager/yew-comp 0/8] openid support for PDM

[Shannon Sterz]

On Fri Oct 17, 2025 at 10:01 AM CEST, Fabian Grünbichler wrote:
> On October 14, 2025 3:30 pm, Shannon Sterz wrote:
>> this series adds openid support to PDM. the implementation is based on
>> PBS' implementation with a some adaptions:
>>
>> - smaller refactorings to use more data types instead of simply putting
>>   them together with serde_json::json!
>> - move variables into format strings where possible
>> - only support the HttpOnly variant of the authentication flow
>>
>> when going through this i at first wanted to put most of the api
>> endpoints' logic into a proxmox-rs crate. however, i decided against
>> that as that would have created a couple of other problems. i'll outline
>> different options below and why i decided against them:
>>
>> - access-control: the login endpoint needs to be able to sign a ticket.
>>   currently access-control does not have access to the keyring that
>>   would be necessary for that. the keyring is available in auth-api, but
>>   making it public there has possible other downsides. such as suddenly
>>   making it very hard to audit which parts of our code have access to
>>   the keyring through auth-api.
>
> the keyring is technically public there already (else PDM couldn't sign
> tickets using it as below ;)) - so I would not object in principle to
> also using it in access-control, it's not like that is some random crate
> that has no business being concerned with that.
>
> I do get the point (raised off-list) that access-control parts could be
> used in the front-end as well, but that can be solved by either
> splitting it further or using feature guards where appropriate..
>
> the main benefit of having this in access-control would be at some point
> migrating PBS over as well, but that will surely cause more churn
> anyway, so as long as it is kept in mind that there is code duplication
> there (which is true for the whole auth stack anyway), it's not
> something that needs to be solved now IMHO.
>

hm in that case i'd leave these api endpoints where they are for now and
would focus on factoring out more parts of the realm management + these
api endpoints into access-control later.