From: Krzysztof B. <go...@ic...> - 2015-09-11 10:35:30
|
Dear Gerben, W dniu 11.09.2015 o 11:45, Gerben Venekamp pisze: > 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? OK, now I got it (I think). Sorry to say, but this is impossible (in general, not as Unity can't do something). Simply put you can't provision federated users to a local DB (as LDAP) as you never get user's credential during federated login. [and one remark mostly about wording: if you want to really "federate" your LDAPs you need an additional IdP software (Unity/Shib IdP/...) per each LDAP instance.] You can have your local users in LDAP and federated users (in their IdPs which you can't control). If the federation gateway (as Unity) is down you can still use local LDAP if it is up, but not federated logins - those can not be magically "cached" locally. You can in general ask about a local credential during registration of a first-time federation user. However this won't be federated access anymore and in general makes little sense. For your setup you can go two ways: 1) setup single Unity to be a federation bridge plus expose LDAP login. Setup services to use Unity if available and local LDAP it not (what would be a degraded mode). Easy on Unity side, but can be a lot of work on (all) services side. 2) setup Unity as above but two instances using shared DB (and same configs) plus HA switching e.g. IP in DNS is changed when primary is down. Then you can easily configure services to use Unity. But a lot of work on Unity & its RDBMS side. Best, Krzysztof |