user management - why bother?

[Roland Weber]

Hi Angie, all,

The current Caitrin Proposal mentions user management:
http://wiki.apache.org/incubator/CaitrinProposal
 > The user management system will be based on JAAS. [...]


JAAS is not an API for user management. It is an API for
authentication (check passwords) and authorization. If you
want to provide a web service for accessing the gallery,
I assume that you have a servlet container (Tomcat) or
JEE environment (Geronimo). In that case, I would never
try to deal with user management myself, but always leave
that to the container. The container itself might use JAAS,
but that's not a concern of the application.
The authorization component of JAAS by default evaluates
static policy files. That's not something you would use
to manage list of friends.

It is reasonable to use an LDAP directory like the
Apache Directory Server to manage a group of friends
for every user. But permission checking should be left
to the backend if possible. I don't know what JCR offers
for that at the moment.
Managing the groups in the LDAP is a different problem,
I'm not sure whether you should try to handle that at
all as part of the photo gallery. Preferably not with
the first shot at least. Common APIs for accessing LDAP
are JNDI [1,2] and JLDAP [3].

To keep the workload manageable for the start, I recommend
to leave user management completely out of the scope.
Just assume a limited number of user groups, like
"everybody", "everybody logged in", "self". Maybe add
two or three tiers for fun, like "long-time users" and
"admins". The point here is that this can be handled by
a bunch of J2EE roles which anyone can map to groups in
the user repository. Once you have a group of friends
for every user, that is no longer possible. Of course,
that all depends on the access control mechanism that
Jackrabbit provides. I'm not familiar with that.

Btw, the Caitrin Proposal currently looks more like the
draft of a high-level architecture document rather than
a project proposal. I guess it will need a bit more work
to convince the Incubator folks.

cheers,
   Roland


[1] http://java.sun.com/products/jndi/tutorial/ldap/models/jndi.html
[2] http://www.javaworld.com/javaworld/jw-03-2000/jw-0324-ldap.html
[3] http://www.openldap.org/jldap/

---------------------------------------------------------------------
To unsubscribe, e-mail: projects-unsubscribe@...
For additional commands, e-mail: projects-help@...

[Angela Cymbalak]

Roland,

Again, thanks for the feedback.  My documentation skills need
improvement apparently.

At 07:28 AM 7/11/2008, Roland Weber wrote:

>JAAS is not an API for user management. It is an API for
>authentication (check passwords) and authorization. If you
>want to provide a web service for accessing the gallery,
>I assume that you have a servlet container (Tomcat) or
>JEE environment (Geronimo). In that case, I would never
>try to deal with user management myself, but always leave
>that to the container. The container itself might use JAAS,
>but that's not a concern of the application.
>The authorization component of JAAS by default evaluates
>static policy files. That's not something you would use
>to manage list of friends.

Yep, you are completely correct.  And I can't even really tell you
what I was thinking at the time.

>It is reasonable to use an LDAP directory like the
>Apache Directory Server to manage a group of friends
>for every user. But permission checking should be left
>to the backend if possible. I don't know what JCR offers
>for that at the moment.
>Managing the groups in the LDAP is a different problem,
>I'm not sure whether you should try to handle that at
>all as part of the photo gallery. Preferably not with
>the first shot at least. Common APIs for accessing LDAP
>are JNDI [1,2] and JLDAP [3].

I personally think that LDAP might be overkill.  To answer the
question presented: why bother?  To be able to keep photos public,
protected or private.  Public: anyone can view, protected: your
friends can view, private: only you can view.  I could probably be
convinced that user management should be a 2.0 feature but it seems
that it could be an important part of the end user experience.

>Btw, the Caitrin Proposal currently looks more like the
>draft of a high-level architecture document rather than
>a project proposal. I guess it will need a bit more work
>to convince the Incubator folks.

Yes, which is another reason why I haven't called for a vote.  The
proposal just isn't ready.

Angie



---------------------------------------------------------------------
To unsubscribe, e-mail: projects-unsubscribe@...
For additional commands, e-mail: projects-help@...

[Roland Weber]

Hi Angie,

> I personally think that LDAP might be overkill.  To answer the question
> presented: why bother?  To be able to keep photos public, protected or
> private.  Public: anyone can view, protected: your friends can view,
> private: only you can view.

See, that's the problem... "protected: your friends can view".
"Friend" is not something that you can map to a J2EE role, like
HttpServletRequest.isUserInRole("Friend");
Every user has a different group of friends. If you want to
maintain such groups, you're right in the middle of user mgmt.
If you don't, you need to define an API where you are later
going to plug in this user management.
"Public" and "private" can be handled without user management.
If you use a system identity to connect to the JCR repository,
you can query and store the user identity via
HttpServletRequest.getRemoteUser() or
HttpServletRequest.getUserPrincipal().
How exactly these calls are mapped to the user registry depends
on the container and doesn't affect the application.
If you connect to the JCR repository with the user identity,
it depends on the ACL capabilities of the repository how to
implement those. Still, "public" and "private" are the two
things that I would expect to be available in any case.

If you have "friends" for a user, things change. You have to
consider more than the identity of the user that is logged in.
The "friend" relationship needs to be stored somewhere, and
it needs to be queried. You have to deal with the identities
of the users owning the photos and query their friends to see
whether the current user is among them. Or else you have to
query for the current user "whose friend am I?".
If you want to do that on the application level, you need
access to a user repository where you can query users and
groups. If you want to handle it on the repository level,
you'll find yourself implementing a Jackrabbit AccessManager.
The first option is ugly, the second one slightly off scope
for the moment (imho).

> I could probably be convinced that user
> management should be a 2.0 feature but it seems that it could be an
> important part of the end user experience.

I wasn't suggesting to delay it to 2.0. Rather 0.2, where
0.1 alpha 1 is the code you'll bring into the podling.
You have no developer community yet. My suggestion is
to focus on the core functionality while you grow that.

It's good to give thought to and keep an eye on everything,
but you don't have unlimited resources to get the job done.
The best way to get people interested is to deliver code
they can play with, code that works and can be extended.
If you're trying too many things at once, neither will
get finished.

cheers,
   Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: projects-unsubscribe@...
For additional commands, e-mail: projects-help@...

[Noel J. Bergman]

Roland Weber wrote:

> The current Caitrin Proposal mentions user management:

> JAAS is not an API for user management. It is an API for
> authentication (check passwords) and authorization.

Have you asked what the proposal means by user management?  If it is
intended as an umbrella that covers authorization, then JAAS is a potential
fit, although we have another potential project that would also serve.

> I assume that you have a servlet container (Tomcat) or
> JEE environment (Geronimo). In that case, I would never
> try to deal with user management myself, but always leave
> that to the container.

JEE container managed security does not cover instance based authorization,
and would not address which part(s) of a gallery a given entity can access.

> It is reasonable to use an LDAP directory like the
> Apache Directory Server to manage a group of friends
> for every user. But permission checking should be left
> to the backend if possible. I don't know what JCR offers
> for that at the moment.

The fact that we might be able to defer to some other part of the system and
not use JAAS directly does not eliminate the issue of wanting fine-grained
access control on elements.

        --- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: projects-unsubscribe@...
For additional commands, e-mail: projects-help@...

[Noel J. Bergman]

Noel J. Bergman wrote:
> Roland Weber wrote:

JEE container managed security does not cover instance based authorization,
and would not address which part(s) of a gallery a given entity can access.

> > permission checking should be left to the backend if
> > possible. I don't know what JCR offers for that at
> > the moment.

From the docs:

  How do I manage the access rights of authenticated users?

  The current JackrabbitSimpleAccessManager class only supports
  three access levels: anonymous, normal, and system. Anonymous
  users have read access while normal and system users have full
  read-write access. You need to implement a custom AccessManager
  class to get more fine-grained access control.

q.v.
http://jackrabbit.apache.org/api-1/org/apache/jackrabbit/core/security/Acces
sManager.html
     http://markmail.org/message/cc3lgit3fff5gcse

        --- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: projects-unsubscribe@...
For additional commands, e-mail: projects-help@...

[Roland Weber]

Noel J. Bergman wrote:
> Roland Weber wrote:
>
>> The current Caitrin Proposal mentions user management:
>
>> JAAS is not an API for user management. It is an API for
>> authentication (check passwords) and authorization.
>
> Have you asked what the proposal means by user management?

Nope. I just assumed that user management is about managing
users and groups :-)

> If it is
> intended as an umbrella that covers authorization, then JAAS is a potential
> fit, although we have another potential project that would also serve.

That would be JSecurity?
http://www.jsecurity.org/


>> I assume that you have a servlet container (Tomcat) or
>> JEE environment (Geronimo). In that case, I would never
>> try to deal with user management myself, but always leave
>> that to the container.
>
> JEE container managed security does not cover instance based authorization,
> and would not address which part(s) of a gallery a given entity can access.

It covers authentication and statically assigned roles.
Hence my suggestion to lower the authorization requirements
to a level that can be easily implemented based on the
information that JEE offers. A username is readily available,
and so are the roles of the current user.

You're right of course, it is necessary to store the access
control information somewhere. Either with the photos in the
gallery backend, or somewhere in the authorization component,
or both. It will not be possible to simply defer this question
as I had hoped. JCR 2.0 comes with an API for authorization,
but it's not here yet.


cheers,
   Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: projects-unsubscribe@...
For additional commands, e-mail: projects-help@...