libregraph / idm Goto Github PK

When writing entries idm should provide at least some basic schema checks:

• make sure objectClass Attribute is present
• make sure the RDN attribute is present on the AttributeList, if not, add it
• normalize AttributeTypes and objectClass Values

ideally we'd also add some syntax validation for the basic LDAP Syntaxes and validation for required and optional Attributes for the specified objectClasses.

The boltDB backend should support basic search indexes for at least presence, equality and prefix matches.

We shoudl add support for some core operational Attributes. Namely:

from RFC4512:

• creatorsName: the Distinguished Name of the user who added this entry to the directory,
• createTimestamp: the time this entry was added to the directory,
• modifiersName: the Distinguished Name of the user who last modified this entry, and
• modifyTimestamp: the time this entry was last modified.

from rfc4530:

• entryUUID

I am opening this issue to document some ideas we have at ownCloud.

We would like to be able to communicate with the idm using the Graph API. The API should provide read and write access, so that we can do basic CRUD actions.
This means that the idm needs some sort of storage which could be implemented using https://github.com/tidwall/buntdb for example.

cc: @micbar, @butonic

CI needs to be added to this project via GitHub Actions.

The panic recover in

For example when for whatever reason a user record has no userPassword field, the nesting code in server/handler/ldif/entry.go goes like

ldappassword.Validate(bindSimplePw, entry.UserPassword.Values[0])

and that panics.

Panics should be logged so it is clear why Bind commands return an Operational Error and this particular case should not panic in the first place.

For exampe the DN uid=A\+B,ou=test when fed into ldapdn.ParseNormalize is turned into uid=a+b,ou=test, which actually is a and invalid encoded DN as the + has a special meaning in DNs.

@fbartels It would be great if you could take care of the README in a similar fashion when you have the time.

Originally posted by @longsleep in #2 (comment)

The used go-crypt module contains glibc specific code. Alpine linux is using musl instead of glibc.

owncloud/idm # make
running gofmt ...
retrieving dependencies ...
# github.com/Azure/go-ntlmssp v0.0.0-20211209120228-48547f28849e
...
building cmd/idmd ...
CGO_ENABLED=1 go build \
        -mod=vendor \
        -trimpath \
        -tags release \
        -buildmode=exe \
        -ldflags '-s -w -buildid=reproducible/0.3.0-41-gb89b052 -X github.com/libregraph/idm/version.Version=0.3.0-41-gb89b052 -X github.com/libregraph/idm/version.BuildDate=2022-02-17T17:28:53Z -extldflags -static' \
        -o bin/idmd ./cmd/idmd
# github.com/amoghe/go-crypt
vendor/github.com/amoghe/go-crypt/version.go:6:10: fatal error: gnu/libc-version.h: No such file or directory
    6 | #include <gnu/libc-version.h>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:47: cmd/idmd] Error 2

To be able to properly log messages of the ldap module idm is "redirecting" the standard logger to logrus:

https://github.com/libregraph/idm/blob/master/server/server.go#L131

We are currently trying to embed the idm service into ocis and this is creating a bit of on issue with any other go module that might be using the standard logger. (All messages will get the scope=ldap thing added, even if they come from completely unrelated code).

Maybe we should make that log redirection optional somehow.

I am opening this issue to document some ideas we have at ownCloud.

We would like to have a basic web UI to manage users. The web UI could talk to the idm using the graph API #9
These operations could be:

• list users
• add users
• delete users
• lock users

This web UI doesn't necessarily need to be included in this repository, I just wanted to document this somewhere.

A first idea was to port the UI from our accounts service. https://github.com/owncloud/ocis/tree/master/accounts/ui

This also opens some implicit requirements like we would like to send invitation mails when adding users.

cc: @micbar @butonic

While the server does not return more results than request. It does return the proper SIZE_LIMIT_EXCEEDED error in that case.

ldapsearch -x -H ldaps://:9235 -D uid=libregraph,ou=sysusers,o=libregraph-idm -W -b o=libregraph-idm -z1
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <o=libregraph-idm> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# libregraph-idm
dn: o=libregraph-idm
o: libregraph-idm
objectClass: organization

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

idm currently chokes on some filters that contain escaped characters in the filter assertions. E.g.:

ldapsearch -x -H ldaps://:9235 -b o=libregraph-idm "(member=uid=a\5c+b,ou=users,o=libregraph-idm)"
[..]
# search result
search: 2
result: 1 Operations error

# numResponses: 1

where (member=uid=a\5c+b,ou=users,o=libregraph-idm) is a correctly escaped filter.

The reason seems to be that DecompileFilter (https://github.com/libregraph/idm/blob/master/pkg/ldapserver/filter.go#L63), imported from
github.com/nmcclain/ldap at some point. Does not correctly re-escape filter assertions when regenerating the string representation of the filter from BER.

IDM should offer basic SSL support by adding an ldaps;// listener. (Support for the StartTLS operation would be nice, but I guess we could do without that.)

With the current implementation anybody who can successfully do a non-anonymous bind gains full write access to the entire LDAP tree. We should rework that to allow write access only for a single user, specified via CLI flag.