[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.
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...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the security-dev
mailing list