[security-dev] IDM API/Implementation

[Bill Burke]

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:
> 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...
>>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com