[security-dev] IDM Realms and Applications - The Nitty Gritty
Bill Burke
bburke at redhat.com
Thu Nov 15 18:28:44 EST 2012
I took a look, some thoughts:
* Doesn't seem to do anything with authorization (role mappings)
* Scope is not taken into account?
* It is not integrated with AS7/JBoss web so that you can use security
constraints or propagate the Subject.
* I'm not sure how useful creating a dependency on Amber is. OAuth2 is
not a difficult protocol to implement.
Picketlink IDM 3.0-2012Oct30 has a non LDAP mapping?
On 11/15/2012 5:31 PM, Anil Saldhana wrote:
> PL OAuth implementation at https://github.com/picketlink/picketlink
> uses IDM. I am waiting for IDM API to stabilize. You may want to take
> a look at the test cases I have for oauth.
>
> On 11/15/2012 04:25 PM, Bill Burke wrote:
>> FYI, I'm ready to implement OAuth2 and custom REST protocols on top of
>> this IDM whenever something usable is ready. Both the REST interface
>> for the IDM, the AS7 integration at the protocol level, and the JAX-RS
>> client integration.
>>
>> On 11/15/2012 4:42 PM, Anil Saldhana wrote:
>>> Good feedback, Bill.
>>>
>>> We are currently writing test cases. We definitely need to wire up
>>> your use case in a test. That way, we can fine tune the model.
>>>
>>> On 11/15/2012 02:25 PM, Bill Burke wrote:
>>>> I don't think your design incorporates the idea of a distributed
>>>> application: a set of services and websites that makes up one
>>>> application. In other words the fun SOA buzzword.
>>>>
>>>> In my mind, you have a bunch of distributed services. Each service may
>>>> or may not have its own roles and role mappings. A user is allowed to
>>>> execute on a set of services and those services may call other services.
>>>> For example: a user may interact solely with Website A, but Website A
>>>> may need to interact with other services.
>>>>
>>>> So, the actors would be Realm, Applications, Services, Users.
>>>>
>>>> On 11/13/2012 7:26 PM, Shane Bryzak wrote:
>>>>> I'd like to go through the proposed design for Realms and Applications
>>>>> in detail, as this is quite an important feature to get right and we all
>>>>> need to be on the same page with this before we proceed.
>>>>>
>>>>> To start with the basics, let's look at the relationship between Realms
>>>>> and Applications:
>>>>>
>>>>> Realms and Applications
>>>>>
>>>>> Each realm is a totally segregated "island" of identity state, with no
>>>>> crossover of state between the realms. Applications, Users, Groups and
>>>>> Roles only exist within the scope of their containing realm. Realms are
>>>>> top level constructs, and due to reasons of complexity and practicality
>>>>> we don't support a Realm "hierarchy"; i.e. there are no Realms within
>>>>> Realms.
>>>>>
>>>>> Let's take a look next at how Users and Groups fit into this:
>>>>>
>>>>> Users and Groups
>>>>>
>>>>> All User and Group objects are first class citizens within a Realm. If
>>>>> we think of this in terms of the corporate model, a company may be
>>>>> represented by a single Realm, with its employees as Users. Each
>>>>> department and sub-division could be represented as a Group, with Users
>>>>> (employees) belonging to one or more of these Groups. There is also a
>>>>> hierarchy for Groups, which allows greater flexibility in defining the
>>>>> company structure. Let's take a closer look at how this structure is
>>>>> defined:
>>>>>
>>>>> User and Group Memberships
>>>>>
>>>>> Each User can be a member of zero or more Groups, while each Group may
>>>>> be a subgroup of one parent Group.
>>>>>
>>>>> Let's take a look at Roles next. While both Users and Groups sit at the
>>>>> top level of the Realm, Roles are all application specific:
>>>>>
>>>>>
>>>>> Roles
>>>>>
>>>>> Each Application may define zero or more Roles, each of which may be
>>>>> used within the scope of the Application's authorization rules to
>>>>> determine the appropriate privilege levels for Users. Roles may be
>>>>> granted to either a User or a Group, as illustrated by the following
>>>>> diagram:
>>>>>
>>>>>
>>>>> User and Group Roles
>>>>>
>>>>> Each role may be granted as an Application Role (i.e. a Role membership
>>>>> that has no Group component) or as a "standard" Role (which does have a
>>>>> Group component). An Application Role is used to grant broad
>>>>> application privileges to a select User or Group, for example you might
>>>>> wish to grant an Application-specific "admin" role to all members of the
>>>>> "/employees/itdepartment/managers" Group. A standard role is used when
>>>>> you wish to grant a Group-specific privilege to either an individual
>>>>> User or a Group of Users, for example granting a User the Role
>>>>> "TechSupport" for the Group "/department/cardiology/doctors".
>>>>>
>>>>> So in summary, PicketLink will support:
>>>>>
>>>>> 1) Realms, which represent top level boundaries of segregated identity
>>>>> state, and are arranged in a flat (rather than hierarchical) structure.
>>>>>
>>>>> 2) Applications, which essentially represent a group of services and
>>>>> resources.
>>>>>
>>>>> 3) Roles, which are specific to an Application and are defined for the
>>>>> purpose of controlling access to the services and resources provided by
>>>>> the Application.
>>>>>
>>>>> 4) Users, a top level construct within a Realm that represents an entity
>>>>> that may access the services and resources provided by one or more
>>>>> Applications.
>>>>>
>>>>> 5) Groups, another type of top level construct within a Realm, arranged
>>>>> within a hierarchical structure and that may be used to define broader
>>>>> associations of Users and sub-Groups for the purpose of assigning
>>>>> coarse-grained privileges to an Application's services and resources.
>>>>>
>>>>> Impact on Identity Management API
>>>>> -----------------------------------------------
>>>>> One of the most important factors in implementing support for Realms and
>>>>> Applications is the impact on the IDM API. As a primary goal for
>>>>> PicketLink is to provide a simplified API for developers, this support
>>>>> must be provided in a manner that doesn't pollute the API with
>>>>> unnecessary complexity. To that end, let's start by looking at the
>>>>> simplest use case, in which a developer embeds PicketLink into their own
>>>>> application.
>>>>>
>>>>> Default Realm and Application
>>>>> --------------------------------------
>>>>> To allow for a developer to use PicketLink in the simplest way possible,
>>>>> I propose that we introduce the concept of a "default" Realm and
>>>>> "default" Application. By doing this, we can allow the developer to
>>>>> simply use the basic PicketLink API without having to be aware of these
>>>>> more advanced features. For example, let's pretend that the developer
>>>>> wants to create a new User:
>>>>>
>>>>> User user = new SimpleUser("jsmith");
>>>>>
>>>>> If we were forcing the developer to deal with Realms and Applications,
>>>>> they would then have to write something like this to create the new User:
>>>>>
>>>>> identityManager
>>>>> .forRealm("default")
>>>>> .createUser(user);
>>>>>
>>>>> However by assuming that an unspecified Realm is the "default" realm,
>>>>> the code looks like this:
>>>>>
>>>>> identityManager
>>>>> .createUser(user);
>>>>>
>>>>> If the default Realm doesn't exist at the time, it will be created
>>>>> automatically (the same goes for the default Application).
>>>>>
>>>>> Likewise, when creating a new Role:
>>>>>
>>>>> Role role = new SimpleRole("admin");
>>>>>
>>>>> The developer would have to write the following code if we didn't
>>>>> support a default application:
>>>>>
>>>>> identityManager
>>>>> .forApplication("default")
>>>>> .createRole(role);
>>>>>
>>>>> If we do support a default though, the code looks like this:
>>>>>
>>>>> identityManager
>>>>> .createRole(role);
>>>>>
>>>>> As a side note, the above examples are slightly contrived because the
>>>>> forRealm() and forApplication() methods wouldn't accept a String (rather
>>>>> they'd expect either a Realm or Application object) - this leads us into
>>>>> our next point.
>>>>>
>>>>> Realm and Application Management
>>>>> ----------------------------------------------
>>>>> To properly support Realms and Applications we will require a number of
>>>>> management methods, similar to what we have for Users, Groups and
>>>>> Roles. I propose the addition of the following methods to IdentityManager:
>>>>>
>>>>> void createRealm(Realm realm);
>>>>> Realm getRealm(String realm);
>>>>> void removeRealm(Realm realm);
>>>>> Collection<Realm> getRealms();
>>>>>
>>>>> void createApplication(Application application);
>>>>> Application getApplication(Realm realm, String application);
>>>>> void removeApplication(Application application);
>>>>> Collection<Application> getApplications(Realm realm);
>>>>>
>>>>> This obviously requires the addition of two new classes to the model API
>>>>> also, Realm and Application:
>>>>>
>>>>> public class Realm {
>>>>> private String name;
>>>>> public Realm(String name) {
>>>>> this.name = name;
>>>>> };
>>>>> public String getName() {
>>>>> return name;
>>>>> }
>>>>> }
>>>>>
>>>>> public class Application {
>>>>> private Realm realm;
>>>>> private String name;
>>>>> public Application(Realm realm, String name) {
>>>>> this.realm = realm;
>>>>> this.name = name;
>>>>> }
>>>>> public Realm getRealm() {
>>>>> return realm;
>>>>> }
>>>>> public String getName() {
>>>>> return name;
>>>>> }
>>>>> }
>>>>>
>>>>> Usage
>>>>> --------
>>>>> One other thing I'd like to discuss is usage scenarios, specifically in
>>>>> Java EE6 applications. I'd like to propose that we provide a producer
>>>>> method that supports the following form of injection for the
>>>>> IdentityManager:
>>>>>
>>>>> First of all, injecting an IdentityManager that uses the default Realm
>>>>> and default Application (the most common use case for embedded PicketLink):
>>>>>
>>>>> @Inject IdentityManager identityManager;
>>>>>
>>>>> Secondly, injecting an IdentityManager for a specific Realm:
>>>>>
>>>>> @Inject @ForRealm("public") IdentityManager identityManager;
>>>>>
>>>>> Lastly, injecting an IdentityManager for a specific Application:
>>>>>
>>>>> @Inject @ForRealm("public") @ForApplication("forums") IdentityManager
>>>>> identityManager;
>>>>>
>>>>> It would also be nice if we could provide support for "configure once",
>>>>> where the developer can configure a specific Realm and Application and
>>>>> any injected IdentityManager would default to using them. There's
>>>>> probably a few different ways to achieve this, so if anyone has a
>>>>> preference please let me know.
>>>>>
>>>>> Summary
>>>>> ------------
>>>>> This pretty much describes the entire proposal for Realms and
>>>>> Applications. I'd like all stakeholders to please carefully review the
>>>>> design, in particular the 5 summary points that describe the
>>>>> restrictions of this model. If we all agree on this, then we should be
>>>>> able to release a stable version of the API very shortly. Some further
>>>>> work may be required the bring the configuration and some IdentityStore
>>>>> implementation details inline with the new design, but that won't affect
>>>>> the API.
>>>>>
>>>>> Thanks!
>>>>> Shane
>>>>>
> _______________________________________________
> 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
More information about the security-dev
mailing list