GitLab Deep Dives, 8 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SCIM Deep Dive (Support) APAC Q&A 2020-12-08

Description

Follow up Q&A for SCIM Deep Dive (Support) 2020-12-07
with Cynthia "Arty" Ng, Senior Support Engineer

A

Hi everyone, so this is the skim deep dining follow up for apac.

A

My name is cynthia ing, also known as artie chan, a senior support engineer, and this is a follow-up and you are expected to have already watched a recording uh from yesterday uh thanks everyone joining so we're just gonna. Do q a um for this session and see what questions we can answer uh emily. I see you have the first question: would you like to vocalize.

B

Yeah yep, so I I was just reading the docs that you linked in the issue, and I saw that there's a skim sso for gitlab.com groups and samwell ones, and I'm just wondering how different is it? Is it like the difference, between.com and self-managed is like group level at instance level, or is there like more differences.

A

Okay, let me try to unpack that question just a little bit I'll answer the easy part first, which is that skim right now is not available in self-managed at all.

A

In the slides I do have a link to the issue um so I'll. Just I think sorry, let me just find it. I believe it's on slide three. uh So it's issue one two, eight two, three, uh so that that issue is kind of a bit general but does refer to bringing skim to self made. It also talks about bringing ldap to dot com right.

A

So it's the issues like the specifier will probably be more issues for the specific parts created, but that is the only issue right now that we have that refers to bringing skim to self-manage. So I want to clarify that skin does not exist at all in self-managed right now, so it's only on.com saml is actually a different kind of feature. Part of the.

A

Product, it is, of course, part of sso right, so um just kind of briefly.

A

The way that it currently is implemented is that the self-managed one and the kind of.com the sas one are two different features: they're both called saml, because that's the protocol to use right, but in terms of how it's implemented, it's actually using very different things.

A

um So if you look at the self-managed saml page, it uses certain gems and all this other stuff, I'm actually not even sure how much of the gems we're reusing for uh.com and a lot of it is uh coded differently because it was specifically for dot com specifically for implementation at the group level.

A

So we would always recommend that for customers you're either looking at instance, level for a self-managed and you have saml or in some cases you can do it as on auth, which is again a slightly different thing. The buttons show up in different places too.

A

And you'd be looking, at instance, level configuration git lab rv for com. You are looking at implementation of tying your saml and potentially skim app to a specific group in dot com.

A

Now, the reason why there's a reference to self-managed uh in the saml for groups documentation is because technically it's possible to turn it on. There are feature flags around it, and so you you can turn it on. You can technically get it working, but it's mostly for development purposes. Right and it's I don't.

A

I wouldn't say that it's it's fully functional for self-managed, in the sense that it hasn't been really thought out for the for the user flow and how that would really work for self-managed, and I can imagine it actually being a nightmare to configure, because you can imagine that if you're you have a self-managed instance, if you're doing it at the group level, you have to have a separate saml app for every single group.

A

So if you have 100 groups, you have to have a 100 saml apps and that doesn't make sense right. So if you have a self-managed instance, it makes more sense to implement it. At the instance level and then use groups in terms of access now, group sync is coming so then you would use saml groups to configure what level access people have when signing into saml um like when they sign into samoa. They get added to a group for the first time or something like that or the instance and then based on the saml group.

A

They would have access to certain groups in gitlab, um so you can do that and that's we have it for uh sasfor.com already um so for com. It's you configure samuel for your group and then for specific subgroups. You can say hey if this user is part of this saml group, they should have this role in this subgroup.

A

um So, as a more practical example like say you have um in octa right, say you have a support group right within gitlab right, so gitlab sets up. You know opta for gitlab, you know, and then they say: okay, you have access, obviously to the gitlab group, um but right now I think our default role is guest right um and then, but you could say, hey in the support subgroup, which you know we have um everyone in this octa support group should have maintainer access, so you can set that up. Now.

A

That's that's now available, but that is actually has nothing to do with scale.

A

That is specific to how saml is implemented, um and it has to do with this album protocol and group sync, which again is already available uh for com and is coming. I think in the next release for self-managed at least planned for the next release for self-manage will be available very quickly because self-manage has saml it's just.

A

They don't have skim. So skim is completely separate from everything that I just talked about, and um there currently is no timeline for when skin will be implemented for self-managed.

B

Yeah, thank you. Now I have a clearer picture. Yeah.

A

Yeah, so it is important to remember. Like um you know, I tried to uh slide. Six is kind of where I tried to kind of separate it for everyone. You know, and when I was talking about this during the recording too, uh that saml and skim have two different roles: they're both part of sso right and because they're, both part of authentication and authorization and um and contr. You know, helps to control what users have access to, but ultimately, saml and skin have two different roles within what goes on in the system itself.

A

And that's why you know I was, you know, want to reiterate that skin your skin extern uid can not match what is coming from your sample, like from your identity provider, and you can still sign in because when it comes to signing in you're, only matching on the saml identity and as long as the sound identity matches what your identity provider is sending like, say, octa right, then you can sign in that user can sign in.

A

So it's completely separate from the auto member management, part of it, of automatically adding users and removing them, and that is what skim is specifically designed for in terms of the protocol and what it does so it is.

A

It is two separate things and that's why users in a lot of ways, the users never really directly kind of almost interact with the skim identity, unlike the saml identity, where like when you, when a user signs in you know, gitlab is matching that, against you know, author, whatever identity provider, the user is kind of interacting with it in a way in the sense that they trigger it with skim, it's never user triggered right, it's just it's purely system triggered, and it's purely for managing the addition and removal of users, not to say that you can't manually remove users.

A

If you want to you know it does.

A

Happen: um okay, rotomac! You want to vocalize your question.

C

So we have like skim my api for gitlab.com and in the documentation it's a update, saml identity. So I find that a bit confusing because we have like summer identity and scheme identity and the dark is for a scheme api. But it's a update, some user. So is it for.

A

You know I never actually realized.

A

I usually I don't look at these docs or I don't look at the stocks page in particular, very often because um you know how like we, we can't use the skim api to get this information. So I I rarely use this the stocks page and I I mostly I like.

A

I will point people to it and are our you know our other docs point to this page, but it's really funny, because I actually never noticed that and because we always have to use console to access the skim identity. So.

A

It doesn't touch the sound identity as far as I know it only touches the skin identity. Oh mind, you, I think part of where this came from is is almost like a legacy piece right. It's okay! So we only implemented skim identities in february, but we had skim before that.

A

So we used to only have one identity. We used to only have the samo identity and I think that's why it says some identity, because you actually could use the skim api to edit the same identity in the past.

A

But ever since I think it was about february when, when uh gitlab the you know, the dev team product team kind of turned it on, we created skim identities.

A

So the skim api is now only used for editing the skim identity and it's completely separate from saml. uh So why don't? We add that as duncan, if you can add that, as as an action item um uh wrote now, I don't know if, if you even want to do it, um you can go ahead and, like basically you'd be just renaming saml to skim.

A

Otherwise I mean I can do it too. We can work it out in the action items list but yeah. I think that's just a legacy thing and no one's just ever noticed and changed it.

C

Makes sense like the titles I update a single sample user, but it's on the skin list. So it's kind of a bit confusing yeah.

A

Yeah, I know for sure I definitely think we should edit that um but yeah it's it's it's a carryover from when we used to only have uh one type of identity. uh I think I think I really think that's just where that language comes from. um I bet you if we pulled up the blame right now that it's just that line has not been edited since the doc was created.

C

I agreed um my requests for this.

A

Yeah, thank you um and you want. I see you have another question. You want to vocalize that one.

C

Yep, so this is like more on the sample side because, like um on gitlab.com, like people would sign into a group and then they don't have to sign in for a while.

A

Sorry, I'm laughing because I was literally working on this like an hour ago.

A

Okay, so um yeah so just to clarify, as you mentioned, this has nothing to do with skim. um This is purely a saml thing, um but is tied to sso right because of controlling user access. um We actually well. We as when I say we I mean git lab um a week ago, turned on seven day sample expiry.

A

I have the link handy, and I will add it here, uh so we actually, we literally turned this on a week ago, and then we got a ticket in uh today um and was escalated to me, which is why I know about it um and basically it it now, if you turn on sso and force, uh because it doesn't make sense if you don't turn that on right.

A

So so in the case where someone turns on sso and force, uh then the browser session will force expire in seven days, regardless of our browser policy or browser session policy yeah. So we just turned that on a week ago,.

C

So before it just stayed there forever right, yeah.

A

So it followed our gitlab browser session policy right. So basically, as long as you kept visiting gitlab, um it would auto renew your session uh and you never had to sign it right so like right now, I'm sure you know unless you go on vacation for a week or whatever it is, then, because you visit gitlab almost every day, uh even if you you know you're off for the weekend, you come back on monday. uh Your browser session is still there, like. You, don't have to log back into gitlab right.

A

um So what this does is that it forces it to expire after seven days, regardless of what our uh you know, what the browser section policy is for gitlab in general right, which auto renews this forces the browser session to expire after seven days, so they it forces the user to sign back in to get lab, um and you know the idea for most of these users is that they will be signing in through their provider anyways.

A

uh So it shouldn't shouldn't really change.

A

um What did change actually in this particular instance, and I can try to find the ticket to add to the dock as well.

A

Is that the customer turned on sso enforce actually quite a few months ago, but before they turned on sso and force, they had added users to specific projects and subgroups, and so these users were manually added were not signed in through saml, but even after turning on sso and or they might have signed in through saml in some way or another. um But after turning on sso and force, you're actually not normally allowed to add users to a specific subgroup or project without adding without them being added at the the top level group.

A

um So, but because these users were added both prior to that and then they just kept using gitlab on a regular basis. They were never signed up.

A

So it wasn't until their session expired this week, that they then had problems signing in or getting access because they tried to visit a specific say, project or subgroup, but because they weren't signed in with saml and they hadn't linked their account through saml.

A

Even if they were signed into gitlab, they couldn't access the group itself or the the specific project or subgroup that they were added in so what they had. What they have to do instead is they have to sign in through their identity provider so that they link the existing account to their samo login, create that saml identity right and then that should just give them access back to whatever they already had.

A

At the same time, they would be added at the parent group level or top level group with whatever default role has been set right in the sample settings. So that should be the resolution. We haven't gotten confirmation actually yet from uh this customer, uh like I said, we fairly thoroughly tested this with new users and adding new users, and we just you know, didn't exactly test with hey what, if we manually add users, then turn sso and force on then turn on the feature flag to have a session expire in seven days.

A

um So, if we absolutely need to, we can turn off the feature flag, but it's it's just a browser session expired. We think that as long as the users properly connect their saml identity, uh then it they'll be able to access the group again um so yeah um the doctor and the docs aren't updated. Yet um I actually because this came up today- um I've pinged uh the pm and the backend engineer and asked them about whether there's a docs update in progress um and uh if there isn't then we'll create one.

A

But we should be updating the docs. You know in the next couple days.

C

Thanks, thank you.

A

All right, I realize we're actually just over time um by like a minute or two, so I want to be respectful of everyone's time.

A

If you have any more questions, feel free to throw them in the doc or in the slack channel and I'm more than happy to answer them. Then uh we do have another follow-up uh tomorrow, it'll be outside your time zone, uh but I'm more than happy to answer the questions in a recording, then or again through through the docker through slack as well. So thank you for joining and go ahead and stop the recording.