On 8/22/2012 11:47 AM, Anil Saldhana wrote: I would also suggest text file based impl, as well as a layered hybrid federated solution. What I mean by that is the security developer receives one interface to query from, but the information may be contained in a variety of sources, LDAP, text file, keystore, DBMS, HTTP. For example, a company might not want to store private keys within an LDAP server, but is quite happy storing user/roles in an LDAP server. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

----- Original Message ----- From: "Bill Burke" <bburke(a)redhat.com&gt; To: security-dev(a)lists.jboss.org Sent: Wednesday, August 22, 2012 1:02:57 PM Subject: Re: [security-dev] IDM API/Implementation On 8/22/2012 11:47 AM, Anil Saldhana wrote: Maybe Teiid can be help to create a virtual database for those stores when using a layered hybrid federation solution. If so, we can have a Teiid Identity Manager. Regards. Pedro Igor

I agree that using Teiid can add some complexity. It was just an idea/possibility. I'm sure that a more simple/specific solution can be done using something like you pointed out. Regards. Pedro Igor ----- Original Message ----- From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: security-dev(a)lists.jboss.org Sent: Wednesday, August 22, 2012 6:37:35 PM Subject: Re: [security-dev] IDM API/Implementation On 8/22/2012 3:05 PM, Pedro Igor Silva wrote: Interesting, but do you really want to pull in a huge thing like Teiid for when you just want to store your private keys in a keystore on disk, and your user information in LDAP? I was thinking more of a hierarchy of IDMs you specify in the config of your security domain. If an attribute doesn't exist in the first listed IDM, look in the second, etc... -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

simple federation is easy. But, its a matter of requirements. Sit down and write use cases on different ways you *want* people to use this stuff. For example, development will want simple ways, operations will want more integration. On 8/23/2012 4:21 PM, Anil Saldhana wrote: -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

On 24/08/2012 07:52, Anil Saldhana wrote: Teiid does have an LDAP translator though, allowing the LDAP directory to be exposed through a VDB. Kev -- JBoss by Red Hat

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:

The PL-IDM is a standalone project. It can be integrated in all projects. :) On 08/24/2012 09:56 AM, Bruno Oliveira wrote: