GitLab Feature Walkthroughs, 3 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Manage:: Access - Demo SAML Group Sync

Description

Melissa Ushakov walks through the MVC of SAML Group Sync and talks about the next iterations for this feature.

https://gitlab.com/gitlab-org/gitlab/-/issues/118

A

Hi y'all, I'm melissa, ushuka the pm for the access team, and I wanted to talk to you today about a new feature that we just released called samuel, groupsync and show you how it works and talk about the next steps. As far as iterating on this feature, so saml groupsync has been a highly requested feature, because today we use sso only for authentication and not for authorization.

A

So a lot of enterprise customers have pretty complex setups in their idp, where all users are part of groups and and groups really are what define their authorization and all their different tools and gitlab today isn't able um to read that data and control authorization based on it.

A

So what's going to happen now, is that gitlab will be aware of groups in an idp and we'll be able to grant access at different levels to different groups. Depending on what data we see in saml assertions. So let me show you what that looks like.

A

A

I have an sso enabled group here called melissa sso on gitlab.com, and that's one important piece is that this functionality is only available today on kidlab.com, we'll be working to make that available in self-managed.

A

So you see here in security uh once you have sso enabled you get this menu called saml group links. So if I click on it, uh you can see that you can specify a group name in this and I'm using azure as the idp for my testing.

A

um You put this long guide and you can define what access level people should have that have this group in their sso assertion. So if I find this, I make a maintainer as part of setup. um So this is one part of the setup right on the gitlab side on the idp side. There's a couple things that you need to do. One is in your attributes and claims you have to add a group claim and for our implementation.

A

We look for this specific name so groups, and this is just to simplify things on our side across providers right, but for most providers it's pretty straightforward to customize what that name should be so. I've added the group claims so now it's sent over in the sso assertion to gitlab and then also you need to have users in groups.

A

So I have this specific user called dushikov test that is part of the security and the product group and on the gitlab side, to mix things simply um for the demo. I just did a one-to-one reflection of the groups in my idp in my groups in gitlab. Obviously, people can do more complicated things, but I wanted to keep it simple. So, as a reminder, I have a security group and I've mapped it to this uh name, which is uh this one over here right, so the d, whatever all right so now, the fun part.

A

So this is a git lab user. So this is the usher cup test user that we've been playing with, and you see here that they're part of the product group but they're, not part of the security group, because I updated that right before this demo.

A

So one thing to be aware of with the functionality as it stands today is that we basically need to have an sso interaction for groups to be reflected on and updated on the gitlab side. So if someone's just clicking around and doing their normal work, they won't see groups updated.

A

But if you follow the sso link through your idp and you basically trigger an sso handshake, you'll see that groups are updated. So, as a reminder, I put a link, a group link to be maintainer. If you encounter the group security, so there you go. This is a big deal, because basically now there's one single place to manage group memberships, which is on your idp and as long as you've configured the group links on the gitlab side. Now you can ensure proper membership in the groups on gitlab according to your permissions.

A

um So, as you can see, there's a couple of um next steps as far as iterating on this feature, one is making this available for self-managed.

A

Two is today on gitlab.com, there's a seven day check on your saml, and that was just introduced in the last couple weeks. So, every seven days we require that users basically go through the saml flow to ensure that they still have access on under idp.

A

That is uh pretty long for some customers, so one is: can we make that shorter on gitlab.com without hurting the user experience, so we're going to be looking into how to make that sso check, seamless and two giving that timeout window option have that be configured about the group level?

A

So if a specific group has group um group links or they're just very security conscious if they want to have their users, go through a check every few hours right, they have the option to do that, um but we leave kind of like the default pretty long in general for gitlab.com.

A

So again, this feature is a big deal, because it's the first time that sso is not just for authentication but also for authorization, and it makes setup a lot more simple for big enterprises that are already using their idps for authorization um in you know all their tools.

A

So thanks for watching and if you have any questions, feel free to comment on the saml epic that I'm going to link in this video thanks.