SAML SSO improvements

[Vmihajlovic]

In its current state, our SAML SSO implementation has a significant issue for our users - we don't provision users to projects. This means that when they activate a user on their identity provider side and provision them to our platform, they still need to manually assign them to a project within their org. This means that we are effectively adding a manual step to a process that should ideally be automatic, and most users would expect it to be so. Obvious solution in my mind would be to allow for sending a custom projectID parameter (or any other ones needed based on future plans) from the identity provider so we can capture it and assign a user to a project automatically.

Another approach might be to handle the project assigning on our side - I would see this as more complicated solution both on our as well as user side but mentioning it in case some identity providers would have issues with us sending custom parameters with provisioning requests - where a user would be prompted upon his first login to request access to a certain project directly through the UI and the project admin/owner would be authorising the access.

Any additional feedback would be aprreciated.

[Vmihajlovic]

@mostafa is there something we can do in short term about this?

[mostafa]

I think we had plans for full automation of this process from frontend to backend as a complete cycle. I think this can be done in a short time, but I'd rather finish this cycle and then focus on that depending on the priorities.

@Griatch or @sniku Any comments?

[shric]

I'm the customer who requested this to @Vmihajlovic. To add some extra detail, I would see the ideal approach as simply providing an API to manage user access/roles. Currently, a new user can't even create new projects. If we had the ability to set these capabilities or project assignments via an API then that would be ideal. What did you have in mind in terms of full automation from frontend to backend?

[mostafa]

Hey @shric,

Of full-automation, I meant the user can control activation of SAML SSO from the frontend, which includes instructions, providing access token and other related settings. This way there's no need for concierge service from the CS team, unless the user run into issues. For the project assignment, it can also be part of the automation.

[shric]

Hi @mostafa , thanks, sounds great, Would that enable, for example, all users within certain teams (configured in Okta, our SSO provider) to be added to our specified k6 cloud projects automatically?

[mostafa]

@shric That I should investigate, but I think it's possible. One way would be to name projects according to team/group names, but it should be implemented first.

[vimoudy]

I would like to propose a new role in k6. Something along the lines of Project Manager where someone can add/remove members to projects but not have full blown admin access. Only "admin" access to the projects they have Project Manager permission, if that makes sense.

Also, if there was a way to mirror groups in AD, that would be great. We can create admin, member, project manager groups in AD, then mirror that in k6.

[shric]

We also can't seem to remove users as they leave our org without manually doing this via the UI.

[markjmeier]

This issue is stale with the migration to grafana, closing as part of our migration of this repo to Grafana feature requests