Open Parakleta opened 1 year ago
Hi @Parakleta what about providing template data from a webhook, this is right now possible. There are some docs here https://smallstep.com/docs/step-ca/webhooks
That’s a really nice general solution which I hadn’t come across before, but it is a huge overhead in effort for what I need.
I think a simpler solution like I proposed would also be worth having for those that don’t need that level of functionality/complexity.
Hey @Parakleta đź‘‹, we discussed the issue (at length) with the team and I'll try and give a summation of our thoughts.
There's a significant contingent of the team that agrees with you that this would be a "nice to have" feature. However, the more curmudgeon-y contingent of the team argues that we already have a purpose built way to support what you're asking for - webhooks (as Mariano mentioned). And they argue that, as a project, we don't want to support multiple pathways to accomplish the same task. It adds technical complexity, overhead, and baggage.
Our official position is that using the webhooks is the recommended way to accomplish the task. However, we'll leave the issue open and if it gains enough support from the community we will reconsider.
I appreciate your consideration and detailed response to this issue. I can understand the desire to not add technical debt by having too many separate solutions which all need to be maintained and test, but I would argue that the webhooks solution as provided is in some ways even more complex and inconvenient that the existing ca.json
solution.
While the webhooks solution adds the ability to change the data remotely from another server, what you provide requires (unless I've misunderstood somewhere) me to edit a source file and recompile every time I want to add a user mapping. Obviously I could create my own webhooks server which is more flexible, but by then it would probably be simpler just to change the step-ca program to do what I need.
I would also point out that adding the ability to have includes in the ca.json
file could add other advantages as well relating to separation of concerns with different configurations and services, rather than requiring one single file with all of the configuration and secrets for every service, include the aforementioned templateData
fields. It could allow provisioner or template configurations to be managed in separate files for example.
I'm only passingly familiar with Go, and haven't used the JSON libraries in it before, but I am assuming (hoping) that it should just be a simple case of adding a custom unmarshal rule to inject the contents of another json file in place of an absolute path, which shouldn't be a big change?
Hello!
Issue details
I need to provide custom data per user in SSH certificates and am not able to alter the information returned from the OAuth provider. Currently this means that I need to edit an increasingly complex structure within the
authority.provisioners.options.ssh.templateData
field and I am uncomfortable having to continually edit this file, especially as it contains security information.I'd like a way to include the
templateData
from another json file which can be placed elsewhere on the filesystem with slightly relaxed permissions. As a further extension this might be nice to also support generating thetemplateData
from an executable. An example of similar behaviour elsewhere would be the principals mechanism in SSH.Why is this needed?
This will allow users to attach custom per-user data to certificates while using public OAuth infrastructure. The example provided in https://smallstep.com/blog/clever-uses-of-ssh-certificate-templates/ requires that we are able to add custom claims to the OAuth provider, but it would be nice to be able to control some of these options directly to the certificate authority.