[security-dev] how to model services managed by a realm

[Shane Bryzak]

On 13/06/13 07:05, Bill Burke wrote:
>
> On 6/11/2013 11:27 PM, Shane Bryzak wrote:
>> Bill,
>>
>> I'm currently working on some changes that will allow you to create a
>> custom Partition type, so you'll be able to do something like this:
>>
>> @IdentityPartition(supportedTypes = {Role.class, Group.class})
>> public class Application implements Partition {
>>        private String id;
>>        private String name;
>>
>>        // snip getters/setters
>> }
>>
> Will what you're working on allow you to create partitions on the fly?
> Right now, tiers and realms must be preknown and fixed for the lifetime
> of the IdentityManagerFactory.  I just finished some work to allow File
> and JPA-based stores to be able to create and find partitions and was
> about to submit a pull request.

Yes, it was an oversight that this isn't already supported and Pedro has 
raised a JIRA issue [1] to track it.  It is essentially a configuration 
issue and we'll likely support it via the IdentityManagerFactory interface.
>
>> The supportedTypes member of the annotation allows you to define which
>> identity types can be persisted in your particular partition implementation.
>>
>> I'll also be changing the Partition interface to extend AttributedType
>> (which has getAttribute/setAttribute methods), so it will support
>> setting arbitrary attribute values for partitions, as well as being able
>> to declare formal attributes on the partition implementation itself.
>>
>> I'm a bit unclear about the use case for associating a Realm with Tiers
>> - could you please elaborate on this?
>>
> There is a company-wide set of users.  This is the Realm.  A company has
> a set of distributed applications, each of these applications has their
> own role sets.  I want to assign role mappings from the realm, to each
> one of these applications.
>
>   From a management perspective you'll want to be able to manage all
> application user-role mappings from a specific Realm, or add/remove
> roles from an application.  To be able to do this, you need to know
> which applications are managed by the Realm.
This is already possible without an association between the Realm and 
the Application, however we can probably add support for associations 
between partitions if you think it will be a useful feature.

> Also, I want to be able to create a token for an individual
> authenticated user that contains role mappings for each application
> within the realm.

I would probably implement this by storing the actual token values as an 
attribute of the User, and then using the relationships API to define 
the role mappings:

public class TokenRole extends AbstractAttributedType implements 
Relationship {
     // User
     private User user;

     // Application role that this token applies to
     private Role role;

     private String tokenCode;

     // snip getters/setters
}

You would then execute a relationship query to determine which 
application roles the user has assigned for a particular token.


>
> All this needs to work in a SaaS model, where multiple realms can be
> created and managed.
>
> Pedro suggested that I model each Application as a Tier, but I'm having
> doubts about this because LDAP doesn't currently support the notion of a
> partition.  Maybe I could federate this?  Store username/credentials in
> the company's LDAP store, but store application, roles, and role
> mappings within a local store?  Is this type of application data even
> stored in LDAP in reality?
>
>

As previous, I would create a custom Application partition type and not 
try to shoe-horn it into an existing type.  I agree about LDAP, it's not 
designed for multi-partition support and federating is the way to 
achieve what you're describing.  You could store just the basic user 
data in LDAP and everything else in a JPA or JDBC store, just like you say.


[1] https://issues.jboss.org/browse/PLINK-189
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20130613/ac478434/attachment.html