[security-dev] IDM API/Implementation

Pedro Igor Silva psilva at redhat.com
Wed Aug 22 18:17:41 EDT 2012

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.

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

Bill Burke
JBoss, a division of Red Hat

More information about the security-dev mailing list