[security-dev] IDM API/Implementation

[Anil Saldhana]

I would not say Teiid is a bad idea. If we implement everything that 
projects such as Infinispan, Drools and Teiid focus on, to satisfy 
simple usecases,  PicketBox may fall flat when users go in for advanced 
usecases.

Ideally my suggestion to projects is to provide lightweight integration 
points - Infinispan Core,Drools Core and Teiid Core etc,  so when users 
demand advanced caches, rules or virtual directories - it is just a 
matter of adding a bunch of jars and changing configuration files.

I know, it is easier said than done. But you get the idea. :)

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...
>