VMware Pinniped Community Meeting, 15 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Pinniped Community Meeting - April 15, 2021

Description

Pinniped Community Meeting - April 15, 2021
We meet every 1st and 3rd Thursday at 9am PT / 12pm ET.

This week's discussion centered around LDAP Support and Device Code Flow (current project roadmap items). Shoutout to community member, Scott Rosenberg, for sharing his knowledge and expertise with the maintainers as they work on these issues. Full notes and meeting details here: https://hackmd.io/rd_kVJhjQfOvfAWzK8A3tQ

A

All right, hi everyone and welcome to this week's edition of the pinniped community meeting where we meet every first and third thursday of the month at 9 a.m. Pacific time, 12 p.m. Eastern time, when attending these meetings, please read and abide by our code of conduct.

A

These meetings are being recorded and they will be uploaded to our youtube playlist within 48 hours of the recording.

A

If you have anything you would like to put in the agenda while attending this meeting or any future meetings, please do so down here at the bottom, at the discussion topics or if there's anything else like a question, you would like to add to the discussion. Q a here on the github that link is also listed out here, uh looks like we don't have any announcements for the day so we'll just kick it right on over to status, update updates within the project roadmap that is listed also on the github repo.

A

Here you can see what the team is working on and the timeline expectations for those different items. So for this month april 2021 we have ldap support and device code flow and I will kick it on over to matt to go a little bit more detail. There.

B

Sure so um ldap support is coming along pretty smoothly. um I think it might be best actually to refer to maybe ryan, to give a status update on where we're at there.

C

Sure yeah, like you, said it, I feel like it's coming along smoothly, making a little bit of progress every day, um the there's a pr open for it, where you can go and see the commits that have been made so far and the um the eye just went green last night on the pr, including an integration test that does the whole um authorized request, including the user's credentials with the upstream deciding what their downstream username should be and their downstream uid should be.

C

So that was quite a cool step along the way towards getting the feature done.

B

Yeah that so that first story, basically, is the the core ldap flow login flow, which is a lot of work to kind of say that ldap works and then there's some additional stories.

B

I think we intend to include before we deliver uh the next release, which are yeah exactly these ones, group support and then as well support for most common connection options, and I think we we actually have a little bit of discussion that might be useful to get into today or sometime about um trying to validate what we think the most common options are like what which options give us support for 80 percent of the environments that we think customers are using? What gets us to 90 percent? What gets us?

B

I don't think we're ever going to get 100, because ldap is too weird and arcane and um there's so many weird ldap setups out there, but um trying to try to get the most bang for the buck and also ship something that is generally useful to most people from the first version.

B

So I think we can talk about that in this meeting or we could. We could talk about it later. um The other, so the other epic, that we have the the on the roadmap for the next release is device code flow support. um I feel like we were very unlikely to ship this in april.

B

um Oh another, another thing about the the roadmap: here we may ship a 080 release that includes some other smaller fixes um and then bump each of these numbers forward by one. um What to see, I think we have some changes that are merged already for caching um there's, a bug fix for the bug fix I'm working on for clusters that are suspended and resumed um those those don't work right now very well.

B

We might take those fixes and go ahead and release that kind of released with those fixes and then shift ldap. In the next phrase. I don't know, I think it kind of depends uh whether we think so. Certainly it could be valuable to have these bug fixes if you're using ocefno today, um if ldap is ready around the same time that we're ready to ship this other stuff which might be you know the towards the end of the month.

B

um I don't think there's any harm in merging them together, because there's not uh the ldap code, if you're not using it shouldn't, have a big stability impact or anything like that. Like there's, there's uh no reason you wouldn't want ldap support, okay um device code flow support. I think, if you click through, there is a something of a stub issue.

B

um Device authorization grant is basically a login flow, it'll, be the lug and flow between the cli and the supervisor, and currently that flow requires the cli to open a local host listening port um and then the browser opens up and at the end of the browser flow you redirect it back to that localhost port and that's how the cli then is able to read your tokens for your session and that's totally functional and works just fine for most people.

B

But if you happen to be like an enterprise windows user and you have some security, local firewall, that's going to freak out. If you open a listening port, you might just not be able to use pen event today so device code flow support is one standard way of doing a login from something like a cli that doesn't require that localhost port. So that's the uh that's the reason.

B

The reason we want to build it is to help support these sort of this subset of users that are unable to use the current login flow, and we haven't had a lot of vocal um requests from those users yet so I think we might be waiting for validation.

B

uh This is a little bit if we were kind of speculating that this is gonna be a problem. If it turns out to not be a problem, then we probably won't build device code flow support, because it's not inherently better or more useful.

B

D

We may we may reshuffle.

B

The roadmap a little bit and and pick up the next thing.

E

Yeah so um matt- and I will be meeting up later today to discuss road map items device could flow. Certainly it's probably going to slip more likely, I think is. We will be doing some work around the docks, which is also represented in the roadmap.

E

And then there are also probably some other uh stories that will make their way in that are around again extending cluster type support, um but this will be updated, probably by end of day today, um taking into account that we have knocked out most of the impersonation proxy work already. um There are a couple of one-off stories that we might prioritize in the backlog as well around that, but we hope that this will be updated soon.

B

Yeah we actually, we have. We have a lot of relatively small stories in the backlog that are like we've been invalidated there in the icebox as well. Probably I went through and validated a bunch of stuff earlier this week and realized that yeah we actually still have a whole bunch of good ideas for things to do to things to improve about our current code.

B

They're, all pretty small, none of them by itself would make like a headline for a release, but I think we need to make sure that, like we're able to work a lot of those things through and that should improve the just overall stability and usability and um correctness of what we've built so far.

B

Well, I think that's really it for the roadmap update. um We don't have any discussion topics unless somebody if nobody has one I'm going to propose that we talk about adapt connection options.

B

I'll even add it to the doc.

A

Matt, do you want to drive for that discussion.

B

I can kick things off yeah. Let me find the um link that we.

B

B

Well, we had another hackmd that had a previous discussion design discussion.

B

B

B

Yeah, so I think some of the options we talked about supporting so we're gonna have uh custom ca support. So so let me talk about the thing we're supporting right now and ryan. You can keep me honest, we're supporting just plain tls with a custom, ca bundle and probably, if you don't specify the ca bundle, you get. The system bundle, that's yeah. Okay, um plain tls in in this context means a tls connection which inside of it carries ldap. I think, and that's one common ldap configuration.

C

um Yeah, maybe more commonly referred to as ldap s, meaning like you, connect directly to the ldap s port and do tls to the lws score.

B

Yes, so it's the same configuration as https or ftps, where you take the existing protocol and wrap it up. um There's at least one other uh connection option that I know is pretty common, which is start tls.

B

Where you speak, it's it's a the reason it exists is as a upgrade mechanism for existing ldap server. If you have a older, ldap server, you want to start supporting tls on it, but you don't have to go fix all your firewall rules till it through a new port.

B

You can turn on tls opportunistically on the same port and it uses a little uh little packet. So basically, the client connects plain text over like plain text ldap and then says hey by the way. uh I see you're an ldap server, I'm an ldap client and I want to speak tls, and then they decide to upgrade that connection to tls sort of in-band um and it can either be opportunistic or in either the server or the client side. You can say that's.

B

The only thing you can do is upgrade to tls and if you don't upgrade to tls, then I'll close the connection um and anyway supporting this should be really trivial, because it's just um like we're using a library that we just need to turn on a flag. I think ryan. Does. That seem to be true.

C

That would have been true because the library supports it, um but the library dialer does not support using a go laying context.

C

um I don't know if the library is too old, like maybe it predates contexts, so I had to write our own dialer to wrap it all up with context support, so it won't just be like the one line of code that you think it should be it'll, be you know, 15 lines of code, not not super hard.

B

Okay, so we'll have to actually send the start: dls packet, ourself and and stuff- I guess that's not so bad. We might uh might be able to contribute that context. Support back to the upstream library too. I don't know how um there's there's a lot of these really fundamental libraries like ldap one comes to mind, but also the oidc library. We use some of the jot jot libraries we use that are very popular in the go ecosystem, but are basically like somebody's side project. That's not really very maintained, um I feel like.

B

We should probably try to get more involved in those projects.

B

I don't really know. I don't know. I don't know how receptive the maintainers are.

F

Going back to the start, tls thing I thought I remember there was a start. Tls function on the connection, interface that we could just call, so we wouldn't have to like construct any packet of sorts.

C

Yeah, it should should be too hard. You just okay,.

F

C

Have to take our own custom dialer and modify it to allow it to also do that. Pretty easy.

B

Okay, so some other options that I think we'd considered. Building, I'm not sure where we landed, one is uh automatic detection of start tls. So I feel like this is still a good idea. So it's saying like not only are we gonna support, star tls and regular tls, but we're never going to even ask the user to tell us which one to use we're always just going to whenever you set up an ldap server, we'll go ahead and try both see which one works and use that one, because they're equally secure.

B

It's just a compatibility thing. um That might be that's additional, like logic for us to write, but.

C

I I realized- I was thinking about that, while I was writing the tls code for the client and realize that um that might be a little tricky, because the the way that we're letting you configure it right now is you give us the host name of your ldap server and optionally. Give us the port that you want to connect to, but you can't give us two ports. You'd have to give us two ports.

C

If you wanted us to try both connection styles, so you could just give us the give us the port.

B

And we'll figure out whether that port is start tls or regular, tls right yeah like it, there tends to be conventional ports for regular ldap and or it's like like 389, I think or like that and then start tl tls ldap is like 489 or something like that. But you could run ldap on whatever port you wanted and we don't.

B

I think we could we could. We could still have a default port of 389 or maybe we could, if you don't specify a port. Maybe we can try the two common ports. I don't I don't know. I feel the feeling would be like, even if you just give us one endpoint, but one tcp you're, basically telling us the tcp endpoint, we'll figure out which flavor of ldap that tcp endpoint speaks.

G

B

Are you referring to like.

H

Auto, detecting.

G

Insecure stuff right because usually the insecure thing is on a different port, then.

C

Yeah yeah, because the start tls way of connecting to ldap you do have to connect to the insecure port and then call start tls like send the start. Tls protocol request over the insecure um so like if we wanted to auto detect- and you only gave us one port number- we wouldn't really know which one to try first, should we try regular tls? Should we try start tls, although I guess matt's right, we could just try one. If we get a tls error, try the other one.

C

Maybe we still get an error, I'm not sure what error we would report, then. Maybe both errors but yeah. The only.

B

Thing, I could think. Oh sorry, I didn't mean to interrupt. The only thing I think is this might be noisy in people's surfer logs, if, especially especially, depending on how often we do this probing like, if we do only once when you create the ldap identity provider, crd and maybe every hour or something like that. Maybe it'd be okay, but if we're doing like this, every three minutes like which is what how we often we resync right now and we're probing and every time we probe on pretty much any server you're going to get.

B

One of them is going to make some kind of error log on the server side, saying like a client connected and got a tls error or a client connected, and um you know, sent a bogus ldap packet because it was actually a tcp handshake at a tls handshake.

B

That might not be great. So maybe the argument there is, we could still have a auto detect mode, but also we need a api flag later to let you hard code, the configuration into the one that one that works, and then we won't try and do these extra probes that we we know are going to be noisy.

G

I mean we could just be sticky right, like you're, it's either going to be tls or star tls right once we find it once for the process. Lifetime.

B

Yeah I mean we we can. We can assume that it never changes once we find it once. That's, probably a pretty good assumption. It's not actually. True, though, like you could reconfigure your ldap server to add tls support on a different port or something and.

G

Isn't one of the core requirements is that you never talk to your ldap admin in any of these things, you don't ask them to change anything about any configuration anywhere other than maybe give you an ldap service account which there's probably a form in your it catalog for request service account. That's a good idea, good! That's a good goal.

B

So I guess I don't know um I feel like, even even with that concern about the the noisy logs, I would still lean towards trying to do this auto detection mode, just because it lets us um have fewer configuration knobs in the api, and we can always add them later, but we can uh start with a default that probably it might just be the permanent solution. It might just be good enough for everyone indefinitely.

G

Pablo you can correct me on this, but the sense I got from a lot of the field stuff that you guys have done is configuring off can be painful, make it less painful and to me this falls within the realm of just there's less choices.

G

All the choices left are meaningful and hopefully somewhat obvious, and thus configuring that that is as painless as we can make it like. We can't figure out what your ldap server is. If we could, then we would do that too. Probably.

E

Yeah you're not wrong um how we go about making this less painful is obviously a running question, um but you're right. That was like a big part of the feedback we got. Was identity, sucks.

C

So I wonder if we could get away with just not supporting star tls, I don't really have a sense for how common it is. How modern it is.

C

Maybe modern ldap servers just use regular tls. Now that would be great.

D

So I can say I know four relatively large enterprises that use start tls and do not use ldap s currently um that are using uaa, for I mean with authenticating with uh ldap currently, um so I have seen it, but it's definitely not. That prevalent from my experience at least.

E

But it does exist. Yeah, that's helpful, scott. Thank you.

B

I mean, I think I think, there's also servers, I'm trying to think back when I like ran an ldap server. I think we, I think we supported both okay.

B

I think we ended up turning off in secure mode, but we still had an ldap server on port 389 or whatever with start tls, and we also had a native 2ls listener and like just just because out of the the universe of software that we were trying to integrate with an ldap server, some of them only supported realty like ldap s and some of them only supported, start tls and so like.

B

We just ran both and that going back to like the limiting communication with the ldap admin as much as possible or really what we're trying to reduce is like the number of round trips and tickets. You have to file to get this thing configured correctly.

B

um If I know that my ldap server is ldap mycompany.l.mycompany.com and I just try a default ldap port, we should try to maximize the chance that that will just work because I think most in most companies. It should be as simple as I kind of like know my ldap server name, because I ask somebody and or copied out of some other systems config all right. So I sort of know vaguely that I have an ldap server.

B

We can probably take it from there and detect a lot of things. I think they can the connection options here. It gets more complicated when you're talking about the the uh user and group attributes and structure and how to do the searches and stuff. I think that auto detecting those will be much bigger challenge. I think we have that slated for like a future future milestone, but this feels like something we can do. Are there any other connection options? I mean there's um the tls versions. That might be something you have to configure like.

B

We don't really support configuring that on any of our other tls client settings yet, but I wouldn't be surprised if we find ldap servers that only support like tls, 1.0 or 1.1, which is not that secure, but it might actually be fine.

B

um I don't I don't know if we can get away with very good darkness.

G

Thing would save us right.

G

I don't know if the start feels thing uses like older versions of tls under the hood, because it is older.

B

It basically, usually, I think it would just be implemented by the same exact client code or same exact server code. So, like you use, start tls and then, when you realize the connection is now to be upgraded, you pass that socket off to like open ssl and you still have a full, regular, tls handshake. That happens then.

B

So I I don't. I don't know that it matters between ldaphos and start tls. It's with more thinking about like an ldap server. That's you know a 10 year old version of openld app that doesn't support tls, 1.2 or.

B

1.3 there's a line somewhere because I think we've already we've already decided like. We really don't want to support plain text ldap, because that's just a pretty ballet, it's a pretty bad idea. We really shouldn't at least at least, if we're going to ever support it. We need to support it with lots of loud.

B

You know uh flags in the ui or something that say like this is really insecure. Are you sure you want to do this? I hope this is a demo environment. Please don't turn this on. um I think we even talked about. Maybe uh this is a slightly side topic, but if we do have a server like a supervisor, that's configured in like an insecure way on on on on purpose to actually surface that back to the cli.

B

So when you're sitting there looking at the password prompt in the cli, you see a warning that says hey by the way. This server knows that it's configured in an insecure way. Are you sure you want to type your password into this thing and.

A

B

It to the user so that um you don't forget basically.

B

Anyway, so tls version on the client, I'm gonna, I'm gonna write that down, because I don't think we have that written down anywhere.

C

It's another one of those things I wonder if we can get away without doing if we just say 1.2 and above is considered the good versions of tls and what, if we just hard code, 1.2.

C

I'd be really curious if anybody tries that and finds that it doesn't work.

G

Sadly, my personal experience tells me that will not fly having fought tooth and nail for many months trying to convince people that no, we did not need to wire these spaghetti flags all the way down into every component in the past.

G

It's also, I like your compression right I would like to. I would like to have that world instead, where we just do something sane and I have 80 000 maps.

C

These flags that we're talking about if we made a start, tls, true or false flag and a tls version that defaults to 1.2, if you don't set it, these are like trivial to implement and don't put a lot of burden on the user to configure because they're optional with good defaults.

C

Maybe one option would be instead of writing a bunch of fancy, auto detect, auto detect code just give them some really easy to understand configuration knobs that have good defaults.

G

I don't think anything yeah. It's really easy to understand.

C

Like one question would be true or false, with the default defaults, it's easy to understand right.

G

One question: you don't know the implications of the true or the false is what I mean right like what does starkillers mean to like a normal human? I don't know what is tls, and why is this starting.

B

I think I think we can. We can see a potential future where the penniped config looks like the dex config or it looks, and I don't mean to pick on decks but looks like the dex config or the uaa config. That's like got, you know, hundreds of options, maybe hundreds is an exaggeration but lots of options, and it's true that maybe the defaults just work for you. But if you actually are sitting there trying to audit your config and say, is my config, correct and secure.

B

You have to go: read like tons of documentation to figure out what all those options mean.

B

I think that's the cost of adding the options is like it's not that it's that much code for us to support wiring it through it's, not that even like uh you know, a more basic user couldn't just deploy it with the default. It still like reduces the it increases the overhead of like maintaining configs for for environments.

B

I also also wonder like so like, if we add a flag for setting the min tls version, and we set it to 1.2 by default.

B

If I go in my config and set it to 1.0, that should trigger some alarm bells that, like I, have an insecure, config right. um That might be what I have to do in my environment, but, like I I shouldn't be, I shouldn't be able to do that without having a word like unsafe somewhere in my config and it's. But it's not true that it's like.

B

Oh, it's not true that it's always unsafe to us that the min tls version, it's just true, that it's unsafe to set it lower than you know, 1.1 or 1.2, and even that, like it's like kind of a gray area. Right it like depends a lot on taste of preferences, around tls attacks and what you think is plausible on your infrastructure and stuff.

B

Okay, all right, I don't think we have a firm, so there's also a bunch of connection options that we don't have in uh any other place yet around like uh timeouts or connection pool sizes or uh overwriting dns resolution, and instead not not necessarily overwriting dls for dns resolution, but setting the server name to be verified on the tls search separately from the connection endpoint, which is another common config.

B

I see on a lot of clients, not necessarily ldap clients, but just tls clients in general, so that you tell that you tell the tell the code. I want you to connect to ip address. You know 192.168.1.20 and when you connect there, I want the certificate to say ldap.mycompany.com, because I don't actually have a real dns record for ldap.mycompany.com.

B

I just know that it's at that ip, but I issued the cert for a different name than the iep, which I think is like just another one of these like unfortunate realities of how network service. I think this is probably less true on big enterprise networks, but more true on smaller environments.

B

I don't know, does anybody have experience with that or opinions? I obviously would I would default to let's not add options until we need them, but.

C

A particular one kind of sounds like a network administrator, just being lazy and not configuring things appropriately, but yeah. It's probably out there somewhere.

G

The the big one I remember is dns based load balancing where the, where the so you have three ldap servers and you configure your supervisor to point to ldap.company.com and that's just a dns-based load balancer that brown robins against the three, but it like that. Each one has its own cert so like when you try to connect to it the other one like the first one will predict ldap1.company.com and then the connecting component will be like.

G

No, it's not that's, not ldap.com.

B

These are all like misconfigurations of the server. That's that's. Definitely I don't think that's not in question it's just. Do we want to support misconfigured servers in these various common misconceptions.

G

The reason this came up is this was like. Why don't you support this because, like this works with active directory or whatever, like they're like yeah this, this is very common. Do you know space load balancing is very common. You know that I was like okay sure, maybe there's like the way I have gotten around in the past. Is we had a much more uh open-ended idp that was sort of like a plug-in style idp so without without with enough effort you could hook in anything to it.

G

So if you had enough consultants on site, they could glue enough apaches and other things together to pass the right data through work. Just wasn't.

B

Desirable yeah, that is always another option, is we could try to extract out some messy messy messy pieces of this and say that like benefit, doesn't support them, but we're gonna build this little ldap proxy.

B

That does like dns like balancing or speaks other flavors of tls or whatever, and then we we could aim to cover like the 80 or 90 of cases and then still have a way that you can support the other the long tail.

B

I don't. I think I think we talked about that before and decided that like we don't really want to do that, because it's a lot of work to document, but but I think the point of it's like I don't know. If I don't know if we would document it like if you, if you have to pull that piece off the shelf, you better know what you're doing um and you don't need it most of the time.

B

I also have no idea how feasible it is to write an ldap proxy, so might be a lot of work.

G

The way this was sort of framed is what wasn't an ldap proxy. It was a purely generic proxy, so the idea was that you authenticated to the proxy and the proxy would somehow authenticate you to the supervisor and then the standard code exchange would happen afterwards.

G

So it's a way of saying that I don't know how to support your idp, but you can wire it in here's the api. It's still not fun, it's not something I would want to repeat, but.

B

I feel like for the the last three things I just typed out there like the timeouts and connection pools and keepa lives and stuff, I'm pretty confident. We could just find a good default for those like that. It's reasonable for most situations.

B

You always have the other fallback too, which is you can always build a custom copy of the code that can change if there's really any default. Setting that you're really unhappy about you can always fork the code and like build a copy with custom values for custom deployment, but I feel like most of the time you wouldn't need to tweak any of these.

B

If we, if we pick some good defaults and think a little bit about what they should be, I also don't know if our server like, if our client library does connection pooling, but that might be a good thing to understand.

C

It does not so we're in our first version we're not doing a connection poll. Every every request opens a new connection sends several ldap protocol verbs. I think, um but I think that's pretty common with ldap, because the.

C

The connection is kind of stateful in the sense like if you bind as a user you're now bound as that user for the rest of the connection. So you don't really want to like to to authenticate a user. You have to bind as the service account and then bind again as the user.

C

You don't really want to have to bind again as the service account to get ready for somebody else to come along and use that from a pool of connections. It's just much easier to open a connection.

C

Do a bunch of verbs and close the connection and be done with it. I think so, of course, you're paying some overhead there.

G

Yeah, it should be okay right because this is like a once: every nine hours thing per user yeah. But what, if you have uh you know? 10 million users.

B

Yeah, I I agree. It's fine. I don't think this is good yeah if you're, if you're, if you're calling this once per user per day, you could have a lot of. I mean you, probably probably don't it's not it's, probably not fair to think about it averaged over a day, it's probably more fair to think about it, like everybody in my company gets online in the course of an hour or two in the morning. So, however, many users there's a good, it's be really spiky load at particular times of the day.

B

So I also don't think the latency is like super critical right, because you're you're doing this operation in line with a very slow manual, interaction typing your password into the console and hitting enter, and so like. It's not something that um it's not something you expect to be instant, except it's totally fine if it takes a second or something.

G

We don't want it to.

B

G

What's that I was gonna, say I'm willing to bet that after you type in your password and you hit enter the bulk of the time that it takes us to return to. You is fetching your groups out of ldap and then somehow encoding the group somewhere and also sending that back to you.

G

And ryan- and I saw that when we had done the we were playing around with a large group test just literally running the commands took a lot longer because there was so much more data just being shoveled around.

C

D

C

Oidc, so you didn't have to perform explicit group searches which is going to take even more time with all that yeah.

B

Can anybody think of any other options here we might want to specify?

B

Oh a client, we said click tls, client search with something we're not going to add yet.

G

This is only kind of related. I was going to ask so today for oidc. We don't do any um any checks uh when you refresh your token against the parent oidc provider,.

G

And I think we had said we would defer that same style check for now for ldap.

G

Do we think we can kind of build all of that generic, like some concept of giving the refresh token that we hand to the user some kind of encrypted state and they hand it back to us and do some validation, and maybe some refreshing of groups or whatever, like all kind of generically across all idps, just with maybe some interfaces or something I don't know? If I don't know if that matters right now, I was just kind of thinking about.

G

C

Ready right right now we're using fossite's built-in refresh uh token generator, so we'd have to write our own, but it lets you do that. So it's probably not super hard to do that.

C

uh So it seems like theoretically possible.

G

Yeah, I guess I was thinking, does the structure of the ldap code need to be in some particular way to help us be in them? Like I know in the callback endpoint right, we could store data if we wanted to. We don't today for oidc, but we totally could not. Nothing prevents us from doing that. So that's in that same vein. I don't necessarily have a good sense for what ldap is doing in that regard like. Could we do something similar you want to do we have space?

G

Is that reason for reasonable thing that wouldn't cause a bunch of code refactors.

C

C

Ldap is equally plugged into phosite to provide the session storage.

C

Seems possible and right now our refresh endpoint isn't doing anything custom. It's it's pretty much. The default fosite refresh endpoint, uh but we could add custom code there. Of course,.

B

Yeah I'd be interested at some point to explore other ways of using the fossil interfaces.

B

To avoid to avoid storage for some of the other for access tokens too, I know that, like there's, there's some properties that you only get if you store access tokens around like single use and and stuff like that, but all right single use for the auth codes, um revocation support for access tokens, but I'd be interested in exploring the the world where we stopped storing those at all and rely on the client, basically to rely on keeping data and the token itself encrypted and might be.

B

It feels like something that would probably help us scalability, wise or performance-wise at some point in the future I mean obviously it shouldn't.

B

We shouldn't complicate the code until we know that it's a problem, but it feels something like something that we'll want to explore, and then the refresh tokens will be another case like that, where I think we, if we really could always link the downstream refresh to the upstream refresh, there's, not necessarily a reason, we would even have to remember anything about refresh token and keep any state on our site at all, necessarily or at least we could have the option to do.

B

B

Okay, I think we're running out of topics- maybe maybe it's a good time to move on if anybody has any other um any other thoughts on the connection options thing I dropped the issue there. If you think of other options that we think we might need otherwise, does anybody have any other discussion topics.

D

Just one other thing on the ldap, but not on the connections, is active directory. Specifics is that going to be like global catalog or things like that or index. You need to do member colon 1.1., whatever it is in order to get the membership within a group, because there's some weird unique id that active directory uses and a lot of in uh you know specialties within 80..

D

um So just wondering that and nested groups, um one of the most common things we're seeing both in uaa and dex is people limiting the nesting of groups that you go down um in searches because of the time it takes. um So just wondering those two and the one other thing I can point out. That has been an issue in other idps in the past with specifically has been federated domains. So using forests with an active directory, um the idm of vmware has had that issue. Uaa has had that issue. Dex has had that issue.

D

Every idp I've ever used has had that issue at some point.

D

Most have fixed it. So just wondering, if that, if there is going to be anything specific 80 and if those have been taken into consideration.

B

Yeah, that's a good question. We've talked about some of those things before I think uh some of it we've sort of planned to do later.

B

I think we I'm not sure we resolved one of the questions we had about building the apis, though, which is whether we might have a special crd for active directory identity provider that would be distinct but share most of the fields with the like, like generic ldap.

B

We could then like turn up some of these features on, like, like uh the forest support and stuff, like that, you know on active directory by default.

B

Even I mean setting up the api now gives us the structure to later add custom behavior around active directory.

B

I think we also talked about like auto, detecting more things on active directory at some point, um or I think mo even had an idea about in the active directory case having a flow where we actually like, join the domain and discover everything um as a as a uh like a proper participant, instead of just trying to treat it as a a generic ldap directory.

G

Scott, I was going to ask a question. You said that you had issues with decks in regards to like limiting group search. I was just scanning their config and I don't see it is there. Is there something specific because, like as far as I know, dex doesn't support like nested groups, so it shouldn't.

H

Be doing exactly that's the issue, just a lack.

D

Thereof of the support right, exactly uaa does support it and the idm, which are the other two, that I've used just uh frequently and both of them do support uh nested groups and have the capability of saying how deep you want the search to go, because I've been to environments where I've had seven. The most I've seen was 77 layers of nested groups and the search time that it took for idps to do the search. There was absolutely insane, so we limited it to 10 and said you know anything beyond that. Sorry.

D

um But that is something that you know. Dex is not good at.

G

Currently, so that's good to know in my in my previous life, when I had to support nested groups, it was a very specific ask which was make nested groups work in active directory, which is different than generic recursive message search.

G

Do you have a sense for folks care one way or the other? The one in active directory is obviously a fancier query that is efficient, because active directory actually keeps an index, so the client's not doing n queries. It's just one query. Please give me back the nested list.

D

Right, I've only seen the nested groups used in active directory. I've never seen them used in an open, ldap or anything like that environment. um But I see them used all the time in active directory.

G

Because it's because it's like a first class thing, like all the windows ecosystem, just treats it as it's like the normal way to do things and 77.

B

G

Pretty bad, but I have seen like 11 in my like 11 layers of nesting. Well, I guess that wasn't even true I it was how many layers are you away from a parent group that gave you like admin rights on your box? That was the problem. I was solving at the time and it was like 11.. It's like this. No one knows why you're rude on your box anymore. It's just horrible sets.

D

Yeah, no so, but that's been, that is usually an issue in the federation of domains has always been. The forests have been big issues and idps in the past with the different domain names. um I know from unfortunate experience at large enterprises where they have large forests of many many domains.

B

There's another related topic here, which is how how are we going to test all this stuff right now? I think that I think we got a good setup with openldap to make a sort of a local toy ldap server, that we can exercise all our code against, but um we should probably start collecting requirements for what we think our like production scale. Test setup should look like. It sounds like it should be: a big active directory with 77 levels of nested groups, perhaps um but just in general, we we also.

B

This is us now, maybe also moving towards wanting to test kubernetes versions as one dimension that we test across and then as well like idps as another dimension that we test across, and maybe um we might need to rethink a little bit of how we structured ci, so that we can avoid combinatorial explosion of testing all the things all the time.

C

Scott, you had a really good list there. I was trying to capture it in our agenda, so you mentioned uh nested groups and limits for that forests and active directory. I think you had one or two more things. There.

D

Was global catalog as well has some uniqueness to it um also around the ports, um which are different, um but global catalog is unique.

D

I think that was it.

D

Yeah, I can't remember anything else. Right now didn't come up. I think those are the main four things.

C

So I'll uh be very open with my ignorance, I'm not an expert active director user.

C

What is global, catalog in active directory, so.

D

Yeah global catalog is basically used again a lot of times in when you have multiple domains when you have a forest, but it allows you basically, it's a read-only um endpoint that you can access that then allows you to access without knowing necessarily which domain the object is located in within that forest.

C

So you're searching for an object across the forest.

D

Exactly but it can also sink only a subset of your resources across the forest, so it's a real easy way that authentication is done in many enterprises when you have large forests of domains.

D

um So it's not efficient way of traversing a forest of domains.

B

I'm also far from an expert, but I always thought of it. It's like a cache. It's like a cache. That's like a merged copy of a bunch of things, that's easier to authenticate it's easier to like put the data all in one place and merge it um kind of like denormalize the forest.

D

Exactly yeah and that's basically, you only see it in large enterprises. I've never seen it in any small companies used, um but it makes just authentication much quicker when you have over like three or four. I think the best practice that microsoft had put out once was like. If you have more than three or four domains in your forest, then you should use global catalog for.

D

Authentication.

G

So sky, just for clarification. What was the issue that you had with global catalog like when using it like what was the misbehavior on the idm or dex or.

D

G

D

I tried to ping the guy he hasn't answered me yet. I know we had issues by multiple customers with it in um in vidm previously, um and I know that it can be a bit different. It has to do with the ports and just the way that it does the mapping of which domain within the forest it was in. um So it was kind of intertwined with the forest issues um that exist sometimes of supporting multiple domains um and that's where it was kind of coming from.

D

I believe, but there was something in how it's returning back your domain, that the response from global catalog is a bit different than a standard response.

D

um I will try and again ping the uh ping, the guy and I sent him a message. The guy who dealt with this from my team um and then I can, you know, share some more information over. You know slack once I get that info from him.

B

This is super helpful, scott. um It's a really really good, uh really good ground truth for us, as we get into trying to figure out what's important to test and support.

D

I'm glad to help any way I can, because I can't code so at least with this I can hopefully.

B

Well, um does anybody have any other last minute uh discussion topics to wrap up, otherwise I think we are at time.

B

Cool thanks, everybody.

A

All right uh thanks everyone for joining today's edition of the pinnapen community meeting scott. I just want to echo what matt said. Thank you so much for your knowledge sharon. It's super helpful for the team and I'm really looking forward to your continuous engagement with the community and super helpful.

A

Our next meeting is not until may 6th, since there are five thursdays in april and we meet every first and third thursday. So that means we won't meet for another three weeks and that's going to be on may 6th and we meet at 9 a.m. Pacific time, 12 p.m. Eastern time. So we look forward to seeing you then otherwise, we'll see you on our youtube recordings thanks.

A