From: Gerben V. <ger...@su...> - 2015-09-11 09:45:37
|
Dear Krzysztof, Thanks for the reply. I did not explain myself well enough… What I failed to make clear was that the services are of a distributed nature. In other words, the service is run across multiple sites. In this kind of setup, LDAP is already being deployed. When a user has access to a distributed service, it must be able to authenticate for that service at all the different sites the service is hosted. Sites usually have LDAP already running and adding to their existing LDAP infrastructure is relatively easy. What happens is that there is a master LDAP directory, which gets copied (replicated) to all involved sites. This enables that a user is allowed to access a service on any of the involved sites. It also ensures that all local sites do not have to add a user to their local LDAP. It relieves local sites from doing all the same thing and relieves the user in getting access to all sites where the service is deployed. The above described setup requires obviously a registration process. Currently users are added to the master LDAP directories in different ways, but non of them are federated. The idea is to make this registration process federated. In other words we are looking into putting Unity on top of the existing LDAP infrastructure in order to make the LDAP infrastructure federated. There is also a benefit in it. In case Unity is unavailable for authentication, we could fall back to the credentials in the LDAP directory and the service keeps running for those users. Also, tooling already makes use of LDAP and thus those are able benefit from federated authentication. The setup that I am thinking of is depicted in the attached image. In this picture, a users accesses either the service on site A or B. The LDAP could be used to authenticate the users (it will have short lived credentials), or Unity is used for federated authentication. Unity adds or updates the validated user to/in the LDAP directory. Hopefully I have explained myself better this time. :-) What are your thoughts on this? Cheers, Gerben > On 08 Sep 2015, at 23:19, Krzysztof Benedyczak <go...@ic...> wrote: > > Dear Gerben, > > W dniu 08.09.2015 o 09:47, Gerben Venekamp pisze: >> Dear all, >> >> Unity has its own user database and I am wondering if it is possible to >> use LDAP instead. The second use case described in the Unity >> documentation (1.1 Use cases) seems to hint at this. However, the >> remainder of the document does not seem to further detail it. Of course >> the documentation describes how Unity can be configured to use LDAP for >> remote authentication. What I would like to know: is Unity able to use >> LDAP for its user database (instead of using either the H2 or MySql >> databases)? >> > > No, it is not (and won't be) possible. You can only relay on LDAP as an external IdP service. > >> The idea behind this is that Unity can act as a master and replicate the >> LDAP database to its slaves. This could be valuable when Unity for >> authentication is temporally not reachable, but services can still >> validate already known users. It would ensure that people can continue >> using a service in case Unity in not able to provide authentication. > > Well, I don't understand this idea. > > When you write "Unity can act as a master" do you mean that "LDAP instance used by Unity can act as (LDAP) master"? If so: how this would help you? I don't know what for you use Unity, but I assume it adds some value to your setup. And then if Unity is down you won't be able to operate. If you have a mixed setup and some services use LDAP directly, and some (e.g. web) via Unity with its added features, then you can replicate LDAPs and also set up two Unity instances, each configured to use different LDAP - so you have real HA. > > Or do you have another setup in mind? My interpretations are not really aligned with what you wrote... > > Best regards, > Krzysztof > > |