Re: [security-dev] IDM API/Implementation

Some comments on the whole federation aka virtual directory aspect of design This was one of core design decisions in PicketLink IDM 1.x and in the and it turned to just be huge pain to deal with. Use case from portal is like this: LDAP schema is limited while portal needs to store a lot of additional user attributes. Let's store part of this staff in LDAP and part in DB. To solve this PicketLink 1.x has very nice abstraction layers and delegation hierarchy. You have IdentityStore (LDAP, DB). Then you have IdentitytStoreRepository which extends IdentityStore. Here you can implement whatever strategy to route calls to underlaying stores and glue results together. All nicely covered by single point in the SPI. Thats theory. In practice this design is fairly broken. First of all there is huge mismatch between RDBMS and LDAP. Certain operations that are no brainer in SQL are not really doable in LDAP - and vice versa. This is mainly an issue because of performance. Simple COUNT operation from SQL is sometimes not doable in LDAP scenario - meaning that you may need to download everything and count on client side to implement API… It gets even worse if you allow to have part of data in LDAP and part in DB. Then it may quickly turn out that there is no way to implement certain API operations in efficient manner. It is quite a blocker as in real world LDAP can contain huge number of identity data to query. In 95% of use cases it is about integration with corporate LDAP server. Directory which is used by several other systems where you cannot adapt your schema and you rarely need to update some attributes. Also market is mainly dominated with MSAD as everyone with Windows Domain have and integrate other infrastructure with it. So what is the best design? In my opinion this is synchronisation. Basically focus on scalable database IdentityStore. Then query and sync data from LDAP during authentication, events or scheduled operation. It can be fairly efficient as most of modern LDAP servers support something called "changelog" - you can check with entries where updated since last time and resynchronise only minimum delta. In the end you will be able to perform all query operations on database - where it is very easy to tune things with proper SQL - even for fairly complex queries. Other issue with LDAP is flexible nature. There are few ways to represent data in it. Also you can store group hierarchies as real tree hierarchies or just by attribute references (member/memberOf). LdapIdentityStore needs to have certain amount of flexibility. In real life I think you either spot 1 level - so very flat schema - or up to 3 levels. Again - I guess it is best to match MSAD scenario here. Use cases where you just rely on LDAP (or even embed it) are probably more around 5% or even 2%. Main issue here is how to adapt schema - in LDAP creating your own attributes is real pain… and in real organisation it never happens as when server is used by some serious systems administrators won't even let you to touch and adjust it. For embedded LDAP scenario my advice would be to investigate which open source server let you easily adjust schema or create some kind of dynamic attributes. Then stick to just this one and provide good integration. Hope it helps. Bolek. On Aug 24, 2012, at 5:36 PM, Anil Saldhana <Anil.Saldhana(a)redhat.com&gt; wrote: