Re: high level design from wiki

Hello Luciano,

> There is a need for authentication, and authorization that would
> consider some kind of user -> role mapping by album. Authentication
> should be flexible, and quoting Noel, "we should probably not be
> dependent on a particular repository type".

I agree if that refers to a specific implementation.
I disagree if that means defining a new abstraction
for a user repository. LDAP is pretty much the standard
protocol for accessing user repositories, and JNDI
gives a standard API for accessing an LDAP server.

> As for the default one, I
> think we should consider the deployment steps required for a user to
> get the gallery up and running, and use the ones that keep these steps
> to a minimum.

If you want an absolute minimum, then you put users
and groups into a DB and deploy the web frontend
without enabling security in the web container.
Honestly, I don't even want to think about being
that sloppy with respect to data protection.

If you want to prepare for real applicability, then
you should expect that users enable security in the
web container. From that point on, LDAP has the upper
hand because everything nowadays ships with support
for LDAP user repositories.
Ideally, the web container integrates with JAAS.
Then authentication is handled completely by the
web container, while our new authorization component
uses javax.security.auth.Subject.getSubject() to
profit from that. Not having to deal with passwords
will be a significant relief.


> We also need to define how we are going to identify the "friends",
> from what we are discussing, each one will have to create a login, and
> then we need to allow each album owner to restrict/give access to
> these friends.

To get started, I recommend to provide a sample
repository with predefined logins and friends.
That allows for playing around, while we can focus
on the repository. For LDAP, that would be an LDIF
file that can be imported into Apache Directory or
OpenLDAP. I have experience in creating LDAP/LDIF
user repositories for demo setups and could take
care of that.

Eventually, we'll need some registration and
management of friends. But that functionality is
not specific to a photo gallery. We can go looking
for existing components at least for the registration.
Every BB forum, wiki and web mail service does
that kind of thing. At that point, we'll get into
all sorts of trouble to keep out spam bots, to
allow for email confirmation, and so on.
Managing a list of friends or contacts is a common
feature of social networks, or so I've heard. You
send out invitations of some sort that need to be
delivered and accepted to establish mutual friendship.
Simply giving everybody full read access to the user
repository so they can claim friendship with everybody
will not play well with privacy expectations.

By taking the LDAP approach, we can profit from
existing LDAP based tools, or create components
that are re-usable outside of the PicaGalley context.

When somebody tries to integrate the photo gallery
with some existing "Web 2.0" infrastructure, then
there will already be a user management system.
Having our own instead of interfacing with a
standard LDAP won't help then.

I guess you've figured out by now that I believe
user management is something we shouldn't get into
until we have a photo gallery backend to show and
ideally a few potential users presenting real-life
UM requirements and maybe offering help with
implementing them :-)


> Having the access control done on the data store level allows low
> level services (e.g REST access to pictures) to leverage the access
> control in place without much extra code.

+1

cheers,
   Roland


[1] http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JNDIRealm
[2] http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html
[3] 
http://java.sun.com/javase/6/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/LdapLoginModule.html