<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I wouldn't say I've had a eureka
moment, but I think this might be one step closer to a solution:<br>
<br>
<img alt="Realm design take 2"
src="cid:part1.08070706.00080702@redhat.com" height="278"
width="777"><br>
<br>
Here's the major points:<br>
<br>
1) We differentiate between standard roles and application roles.
Standard roles are now defined by the realm, while application
roles are now defined by the individual application.<br>
2. Groups still remain as realm-specific. This is mainly to
address the "corporate" use case, however it's still possible to
use groups within an "ASP" use case by simply mirroring the groups
across all realms. Although for the ASP use case, my
recommendation would just be to implement application security
based on application roles and permissions.<br>
<br>
I *think* that this design offers us a happy medium that addresses
all use cases sufficiently, while remaining relatively simple.
Feedback of course is welcome.<br>
<br>
<br>
On 11/15/2012 07:26 AM, Shane Bryzak wrote:<br>
</div>
<blockquote cite="mid:50A40C6A.7060000@redhat.com" type="cite">
<pre wrap="">On 11/15/2012 05:17 AM, David M. Lloyd wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
There's not really an equivalency here, we do support a full-fledged
(separate) permissions API that supports this style of simple permission.
</pre>
<blockquote type="cite">
<pre wrap="">
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?
</pre>
</blockquote>
<pre wrap="">
I would use Attributes to store this kind of data.
</pre>
<blockquote type="cite">
<pre wrap="">
On 11/13/2012 09:04 PM, Shane Bryzak wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 11/14/2012 12:24 PM, David M. Lloyd wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">Unless I'm grossly misunderstanding the concepts (a very real
possibility), it seems like applications should be decoupled from realms
completely.
</pre>
</blockquote>
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
security-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>