[security-dev] IDM API/Implementation

[Anil Saldhana]

Pedro,
   Teiid does not have an LDAP connector.  It is for databases using jdbc.

Regards,
Anil

On 08/22/2012 05:17 PM, Pedro Igor Silva wrote:
> 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 at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: security-dev at 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:
>> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: security-dev at 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:
>>> Hi all,
>>>       (Shane will add more info to this thread soon)
>>>
>>> Shane has been driving the standalone IDM API/Implementation project in
>>> the PicketLink umbrella. This is a brand new project.
>>> https://github.com/picketlink/picketlink-idm
>>>
>>> The Key classes/interfaces are:
>>> https://github.com/picketlink/picketlink-idm/blob/master/api/src/main/java/org/jboss/picketlink/idm/IdentityManager.java
>>> https://github.com/picketlink/picketlink-idm/blob/master/api/src/main/java/org/jboss/picketlink/idm/model/IdentityType.java
>>>
>>> The Manager has a simple api for user/role/group.  Now each of these
>>> types (User,Role,Group) is an IdentityType (implying they get attributes).
>>>
>>> So for an user, if you want to store/retrieve/represent certificates,
>>> password recovery Qs, you can do so as attributes.
>>>
>>> Currently implementation is done using JPA.
>>>
>>> There is plan to do an LDAP implementation.
>>>
>>> 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.
>> 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.
>>
> 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...
>