> On Jan 22, 2024, at 11:12 AM, Brian Demers <[email protected]> wrote:
>
> Awesome!!
>
> Nothing like that exists, but I think it would be a very useful
> example. Right now all of the sample projects are very basic, using
> hash maps to _store_ objects.
>
> In the back of my mind, I've been trying to think of a way we could
> build a generic implementation that _anyone_ could stick in front of
> an LDAP server.
> While I think that's possible, it's probably overkill at this point
> (given that everybody does LDAP a little different).
>
Similar thoughts. We can parameterize enough to support basic use cases. User
object classes of inetorgperson, person, eduperson. 3 or 4 standard group
classes. GroupOfMembers, ofNames. Posix users and groups (RFC2307)
Advanced scenarios, custom schemas, relationships, non-standard usages, will
require extensions.
> Back on topic, an example that shows how to persist objects to an LDAP
> server would be awesome, over time we can add other functionality
> Complex search, bulk transactions, etc.
> Not all of that functionality is necessary, of a lot of use cases.
> For example, Okta only requires SCIM servers to support a username
> search `filter=userName eq "[email protected]"`
> But per SCIM spec, queries could be MUCH more complex.
>
> Maybe this could be a reference implementation of SCIMple?
Agreed. We’d want it to be built on Apache Directory code. I could throw
something together extending fortress quickly, as it’s already a framework
built on Apache LDAP API.
But, that will bring unnecessary dependencies. Will need to think about this a
bit. Perhaps a new lib/framework. Stripped of everything but what’s necessary
to user and group management. Still needs more advanced capabilities like
connection pooling, configuration management, error handling … (what else?)
before it would be useful in production.
—
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
