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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

I'm not sure I understand the rationale of the relationship between realms and applications. To me the concept of a "realm" in terms of identity management relates more to segregating users into groups based on organizational and technological realities. For example, if I am hosting a multi-tenant application I might have a realm for each of my customers (but only one or a few application(s)). For another example, I might have a realm for application authentication (i.e. regular users), a realm for computer-to-computer authentication (might be identified by public key or certificate or some other atypical principal type), and a realm for administration, all of which are utilized by one or a few application(s).

Unless I'm grossly misunderstanding the concepts (a very real possibility), it seems like applications should be decoupled from realms completely.

On 11/14/2012 12:24 PM, David M. Lloyd wrote: > I'm not sure I understand the rationale of the relationship between > realms and applications. > > To me the concept of a "realm" in terms of identity management relates > more to segregating users into groups based on organizational and > technological realities. For example, if I am hosting a multi-tenant > application I might have a realm for each of my customers (but only one > or a few application(s)). For another example, I might have a realm for > application authentication (i.e. regular users), a realm for > computer-to-computer authentication (might be identified by public key > or certificate or some other atypical principal type), and a realm for > administration, all of which are utilized by one or a few application(s). That's a good point and a valid use case that I thought I had taken into consideration, however thinking about it a little deeper there are some nuances of the design that have question marks over them. Let me think about it a little more and I'll get back to you. > > Unless I'm grossly misunderstanding the concepts (a very real > possibility), it seems like applications should be decoupled from realms > completely. Possibly, and while it's relatively clear that Users would remain within the Realm and Roles would remain defined by the Application, I'm not quite sure where Groups would fit in. My first instinct is to keep them in the Realm also, although I'm not 100% sure... time for some mulling I think. _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

A couple more use case tidbits... Connecting roles to applications is sensible in the respect that most roles are application-specific, however it seems plausible that one might want to have a role which spans applications.

Also it seems that there is a (conceptual) equivalency between roles and simple permissions (in the java.security.Permission sense). Is that equivalency ever formalized anywhere, particularly in the context of a security manager?

Finally it seems to me that there may be benefit in identity-oriented storage for things like application preferences and that sort of thing. Is there any allowance for this concept in this IDM model?

On 11/13/2012 09:04 PM, Shane Bryzak wrote: > On 11/14/2012 12:24 PM, David M. Lloyd wrote: >> I'm not sure I understand the rationale of the relationship between >> realms and applications. >> >> To me the concept of a "realm" in terms of identity management relates >> more to segregating users into groups based on organizational and >> technological realities. For example, if I am hosting a multi-tenant >> application I might have a realm for each of my customers (but only one >> or a few application(s)). For another example, I might have a realm for >> application authentication (i.e. regular users), a realm for >> computer-to-computer authentication (might be identified by public key >> or certificate or some other atypical principal type), and a realm for >> administration, all of which are utilized by one or a few application(s). > That's a good point and a valid use case that I thought I had taken into > consideration, however thinking about it a little deeper there are some > nuances of the design that have question marks over them. Let me think > about it a little more and I'll get back to you. > >> Unless I'm grossly misunderstanding the concepts (a very real >> possibility), it seems like applications should be decoupled from realms >> completely. > Possibly, and while it's relatively clear that Users would remain within > the Realm and Roles would remain defined by the Application, I'm not > quite sure where Groups would fit in. My first instinct is to keep them > in the Realm also, although I'm not 100% sure... time for some mulling I > think. > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev >

On 11/15/2012 05:17 AM, David M. Lloyd wrote: > A couple more use case tidbits... > > Connecting roles to applications is sensible in the respect that most > roles are application-specific, however it seems plausible that one > might want to have a role which spans applications. Possibly yes, especially for roles such as "John Smith is the Manager of the IT Department". It's feasible that a company might wish to deploy multiple applications in which such a role would be relevant. There's (at least) two major use cases that we need to consider in our design. The first use case, which I'll refer to as the "ASP use case" (Application Service Provider) is the one where a vendor provides an application that can be used by multiple clients. A real life example of this is OrangeHRM (which we ourselves use for managing employee leave). Each customer gets their own realm (keeping identity state separate from other customers) and the application defines its own groups, roles and permissions. The second one is the "Corporate" use case. In this use case, there is a single realm that contains all of the identity state defining users and groups that represent the organizational structure of the company. There may be one or more applications that authenticate from this realm, each one controlling access based on the user's group and/or role memberships. Since yesterday I've been wracking my brain trying to work out a design that elegantly addresses both of these use cases while not violating KISS, however I've been unsuccessful so far. The issue mainly lies in the placement of groups and roles - on one side, it seems to make sense to maintain groups within the realm. This is reinforced by the corporate use case in which you should be able to define your corporate structure once, then leverage off that structure to control individual application service privileges. On the other hand, this doesn't make sense in the ASP use case (where everything is application-oriented). Perhaps the answer lies in not supporting groups for the ASP use case... in any case I need to think about this some more. > Also it seems that there is a (conceptual) equivalency between roles and simple permissions > (in the java.security.Permission sense). Is that equivalency ever > formalized anywhere, particularly in the context of a security manager? There's not really an equivalency here, we do support a full-fledged (separate) permissions API that supports this style of simple permission. > > Finally it seems to me that there may be benefit in identity-oriented > storage for things like application preferences and that sort of thing. > Is there any allowance for this concept in this IDM model? I would use Attributes to store this kind of data. > > On 11/13/2012 09:04 PM, Shane Bryzak wrote: >> On 11/14/2012 12:24 PM, David M. Lloyd wrote: >>> I'm not sure I understand the rationale of the relationship between >>> realms and applications. >>> >>> To me the concept of a "realm" in terms of identity management relates >>> more to segregating users into groups based on organizational and >>> technological realities. For example, if I am hosting a multi-tenant >>> application I might have a realm for each of my customers (but only one >>> or a few application(s)). For another example, I might have a realm for >>> application authentication (i.e. regular users), a realm for >>> computer-to-computer authentication (might be identified by public key >>> or certificate or some other atypical principal type), and a realm for >>> administration, all of which are utilized by one or a few application(s). >> That's a good point and a valid use case that I thought I had taken into >> consideration, however thinking about it a little deeper there are some >> nuances of the design that have question marks over them. Let me think >> about it a little more and I'll get back to you. >> >>> Unless I'm grossly misunderstanding the concepts (a very real >>> possibility), it seems like applications should be decoupled from realms >>> completely. >> Possibly, and while it's relatively clear that Users would remain within >> the Realm and Roles would remain defined by the Application, I'm not >> quite sure where Groups would fit in. My first instinct is to keep them >> in the Realm also, although I'm not 100% sure... time for some mulling I >> think. >> >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev >> > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On 14 Nov 2012, at 00:26, 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; This seems good, except we should allow for creating annotations to represent realms, applications etc. A bit like resource producers.

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

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

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

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

On 11/16/2012 06:25 AM, 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. Even the latest design? > > 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. I'd like to see a specific example demonstrating this use case. Would it be possible for the services that make up a single application to simply share the roles defined by that application? Adding yet another layer to the current design is going to really complicate things further.

On 11/16/2012 10:33 AM, Bill Burke wrote: > On 11/15/2012 4:55 PM, Shane Bryzak wrote: >> On 11/16/2012 06:25 AM, 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. >> Even the latest design? >> >>> 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. >> I'd like to see a specific example demonstrating this use case. Would it >> be possible for the services that make up a single application to simply >> share the roles defined by that application? Adding yet another layer to >> the current design is going to really complicate things further. >> > A user might be "admin" for one service, but not "admin" for a different > service. Service "A" might want to invoke on Service "B" on behalf of > the user. Doesn't that have to be conveyed in the model somehow? > > Bill > Maybe what we really need to do is find another name for the abstraction that we're currently referring to as Application. The only reason we currently have Applications is to support application-specific roles, which is exactly what you're suggesting we do for Services.

On Nov 16, 2012, at 2:39 AM, Shane Bryzak <sbryzak(a)redhat.com&gt; wrote: > On 11/16/2012 11:19 AM, Shane Bryzak wrote: >> On 11/16/2012 10:33 AM, Bill Burke wrote: >>> On 11/15/2012 4:55 PM, Shane Bryzak wrote: >>>> On 11/16/2012 06:25 AM, 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. >>>> Even the latest design? >>>> >>>>> 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. >>>> I'd like to see a specific example demonstrating this use case. Would it >>>> be possible for the services that make up a single application to simply >>>> share the roles defined by that application? Adding yet another layer to >>>> the current design is going to really complicate things further. >>>> >>> A user might be "admin" for one service, but not "admin" for a different >>> service. Service "A" might want to invoke on Service "B" on behalf of >>> the user. Doesn't that have to be conveyed in the model somehow? >>> >>> Bill >>> >> Maybe what we really need to do is find another name for the abstraction >> that we're currently referring to as Application. The only reason we >> currently have Applications is to support application-specific roles, >> which is exactly what you're suggesting we do for Services. > > Actually, how about we just introduce a new, hierarchical abstraction > which we call "Tier", and allow roles to be granted at various levels. > This way, the application could be modelled as a parent tier, and > services could be modelled as sub-tiers of the application. Roles > granted at the parent tier level would automatically become inherited by > the sub-tier, so at the application tier you could grant general roles, > then for each service tier you could grant more specific roles. Would > that work? It is a bit hard to digest see impact on the model without a diagram. As this SOA use case is pretty narrow I think we should try to come up with something built around the model. Would be good to try to keep it simple for most common scenarios.

On 11/15/2012 4:55 PM, Shane Bryzak wrote: > On 11/16/2012 06:25 AM, 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. > > Even the latest design? > >> >> 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. > > I'd like to see a specific example demonstrating this use case. Would it > be possible for the services that make up a single application to simply > share the roles defined by that application? Adding yet another layer to > the current design is going to really complicate things further. > A user might be "admin" for one service, but not "admin" for a different service. Service "A" might want to invoke on Service "B" on behalf of the user. Doesn't that have to be conveyed in the model somehow?

Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev