Multiple Servers about identityserver4.ldapextension HOT 17 CLOSED

Thank you for all of the changes. I have created pull request #14 that allows the user to specify a domain without breaking changes.

from identityserver4.ldapextension.

from identityserver4.ldapextension.

I have submitted pull request #11 as an initial attempt to solve this issue.

from identityserver4.ldapextension.

.AddLdapUsers(Configuration.GetSection("multipleActiveDirectory"), UserStore.InMemory);
Multiple multipleActiveDirectory or OpenLdapAppUser MultipleLdapAppUser ?

from identityserver4.ldapextension.

@uchetfield I looked a bit, I think there's a better way of doing it. I will look probably this weekend.

from identityserver4.ldapextension.

@murattdogan I updated my fork of the appsettings to clear up your question. You need to have one section of multipleActiveDirectory that contains several hosts.

from identityserver4.ldapextension.

I'm trying to query openldap and active directory ldap with a single Ldap AppUser. In our structure Open Ldap student Academic Staff Active Dricetory Ldap have I want to combine these two applications. So how do we do it with MultipleLdapAppUser.

from identityserver4.ldapextension.

@murattdogan Unfortunately this cannot be done with my solution. You can have multiple hosts of the same type but cannot have both open ldap and active directory at the same time. @Nordes has stated that there is a better way. I'm open to any suggestions but for the time I committed I could not come up with a working solution to utilize both options.

from identityserver4.ldapextension.

Yes, there's a better way. It requires a lot of changes. I will commit once I can make a "buildable" branch. I am now fixing the in memory/redis configuration and after I think I can do a commit and push. It will not be working fully yet but it will give a good idea how it can be achieved. Maybe later this week I will be able to find some time.

Basically:

• The call .AddLdapUsers<OpenLdapAppUser>(Configuration.GetSection("ldapOpenLdap"), UserStore.InMemory) is not forcing you to use OpenLdapAppUser, you can actually write your own logic. So you could potentially merge everything together (2 different type of LDAP), but this will require you to work harder ;) of course.
• The changes are in the LdapConfig, allow a filter
• Configuration: Ability to receive a list OR a unique item (retro-compatibility
• SearchUser needs to be totally changed in order to search accross multiple servers
• Cache (Memory/Redis) needs to be reworked in order to use an ICollection<LdapConfig> instead of a single configuration.

(Some other changes are also required)

from identityserver4.ldapextension.

Please test my branch features/multi_ldap. I tried it at home and it seems OK for me.

You can configure multiple ldap from the same type (openldap + openldap + ...) OR (active directory + active directory + ...)

from identityserver4.ldapextension.

configure multiple ldap from the same type (openldap + active directory+ ...) ?

from identityserver4.ldapextension.

No same type ... for users. As you may know, the attribute mapping for users in Active directory is different than mapping of user attributes in OpenLdap. The only way you could make them work together is if you make a custom "LdapUser" by implementing the IAppUser (see existing implementation).

So basically what I meant was:

• OpenLdap and ActiveDirectory in the current state are mutually exclusive EXCEPT! if you use the same schema regarding all the attributes and types for your OpenLdap, for which, I really doubt you're doing.

from identityserver4.ldapextension.

For example here:

In case you have the EXACT same attributes you want to map your users (AD/SMB/OpenLdap/etc.) then yes, you can use multiple configurations without any issue. But that case is probably really rare. If you wish and that you have a different schema (SMB per say), then the current code of the LdapExtension allow you to extend it. Please look at the code and make your own implementation if you want to mix AD and OpenLdap. The current built-in is not made for that scenario except, as I said previously, if you have the exact same schema for those attributes.

For the current implementation of many servers (which I don't really recommend), you really need a filter to avoid having the same user existing in both system. Otherwise it will take the first one that match and you might expect strange behaviors.

from identityserver4.ldapextension.

Branch merged. More tests will be needed before a release as a nuget package.

from identityserver4.ldapextension.

@uchetfield , looking now into it.

from identityserver4.ldapextension.

@uchetfield Merged (I used the wrong number in the merge comment :(... but it is).

from identityserver4.ldapextension.

@uchetfield : For info, the only problem I see with your solution is if we use the other flow in order to get a token (not by showing the login page). The domain is not part of the implementation in that case. So just be aware of that.

from identityserver4.ldapextension.