high level design from wiki

[Angela Cymbalak]

There are still many questions that need to be answered regarding
this application.  They are all asked with their appropriate topic
but summarized here:

  * Should the user management default be Apache Directory or a
simple database?
  * How will access control be implemented?
  * Will the Web service just provide data for machine to machine
exchanges or will it default to human readable?
  * Should the project impose a backend data storage mechanism and
schema, or just WS/REST interfaces suitable for pluggable frontends?
  * Should we use JCR or a (relational) Database?
   * The proposal (below) now presumes JCR.  Are we losing anything
by not having a relational database?

The photos and meta data will be exposed via a Web service.  During
discussions on the lists regarding how the code should be written,
the one thing that no one seemed to be able to agree on was how the
photos should be displayed.  Some would like to see them in Flash,
others AJAX, still others as a JSP library.  Exposing the information
as a Web service allows for each of these display formats to be
utilized.  Question: Will the Web service just provide data for
machine to machine exchanges or will it default to being human
readable?  If it only provides for machine to machine exchanges then
a default option for display will need to be provided.  We plan on
looking at the Tuscany SCA implementation to facilitate the WS.

The storage for all data will use Apache Jackrabbit and as logically
follows Sling.  The actual node and property structure has yet to be
determined.  Questions: Should the project impose a backend data
storage mechanism and schema, or just WS/REST interfaces suitable for
pluggable frontends?  Should we use JCR or a (relational) Database?

Access control should provide the option to mark photos as public
(anyone), protected (invite only), or private (just the owner).
Options for managing the invites for each user are LDAP or a simple
database. Permission checking can be implemented in the backend as a
Jackrabbit access manager or in an application layer. Candidate
technologies are JAAS and JSecurity, which both allow for pluggable
authentication.



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

[Noel J. Bergman]

Angela Cymbalak wrote:

> * Should the user management default be Apache Directory or a
>   simple database?

User management is ambiguous.  Are we talking about authentication?
Authorization?  And we should probably not be dependent on a particular
repository type.

> * How will access control be implemented?

TBD, and it may exist at different control points, e.g., at the business
logic level (container or component managed) and data store level
(JCR/JackRabbit).

> * Will the Web service just provide data for machine to machine
>   exchanges or will it default to human readable?

I doubt that the "Web service" would be in any way human readable, by
default or otherwise.

> * Should the project impose a backend data storage mechanism and
>   schema, or just WS/REST interfaces suitable for pluggable frontends?

This comes down to a coupling issue. We need a schema to implement.  We can
publish that, and other JCR using tools could leverage, but they would be
tightly coupled to our schema.  Access via WS and/or REST interfaces can be
more loosely coupled, allowing for schema/interface evolution.

> * Should we use JCR or a (relational) Database?

See prior response, but I believe that we're nominally agreed to hang our
implementation on JCR and see how that goes.

> The photos and meta data will be exposed via a Web service.  During
> discussions on the lists regarding how the code should be written,
> the one thing that no one seemed to be able to agree on was how the
> photos should be displayed.

We should not need to do so, if you're talking about a Web service.  The Web
service client would be responsible for presentation.  What we need to
determine is the Web service interface by which the client would interact
with repository content.

>  Question: Will the Web service just provide data for machine to machine
exchanges

Yes.

> We plan on looking at the Tuscany SCA implementation to facilitate the WS.

Then we'll be talking about SCA for the interface and SDO for the data
types.

> The storage for all data will use Apache Jackrabbit

> The actual node and property structure has yet to be determined.
> Questions: Should the project impose a backend data storage
> mechanism and schema, or just WS/REST interfaces suitable for
> pluggable frontends?

I believe that I've replied to this above.  We need and can document the
repository schema, but users would be more tightly coupled, and risking a
more fragile connection, compared to accessing the content via interfaces.

> Access control should provide the option to mark photos as public
> (anyone), protected (invite only), or private (just the owner).
> Options for managing the invites for each user are LDAP or a simple
> database. Permission checking can be implemented in the backend
> as a Jackrabbit access manager or in an application layer. Candidate
> technologies are JAAS and JSecurity, which both allow for pluggable
> authentication.

As noted above, access control (authorization) can be handled at multiple
points.  The surface area related to authorization should be strictly
limited, and not pervasive.

        --- Noel



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

[Roland Weber]

Hi Noel,

>> * Should the user management default be Apache Directory or a
>>   simple database?
>
> User management is ambiguous.  Are we talking about authentication?
> Authorization?  And we should probably not be dependent on a particular
> repository type.

That was the only occurrence of the term that I left in the
proposal :-) Since Apache Directory was mentioned, I found
it unambiguous there. The real choice is of course LDAP or
relational DB.

>> * How will access control be implemented?
>
> TBD, and it may exist at different control points, e.g., at the business
> logic level (container or component managed) and data store level
> (JCR/JackRabbit).

Good point.

>> * Will the Web service just provide data for machine to machine
>>   exchanges or will it default to human readable?
>
> I doubt that the "Web service" would be in any way human readable, by
> default or otherwise.

:-)

>> Access control should provide the option to mark photos as public
>> (anyone), protected (invite only), or private (just the owner).
>> Options for managing the invites for each user are LDAP or a simple
>> database. Permission checking can be implemented in the backend
>> as a Jackrabbit access manager or in an application layer. Candidate
>> technologies are JAAS and JSecurity, which both allow for pluggable
>> authentication.
>
> As noted above, access control (authorization) can be handled at multiple
> points.  The surface area related to authorization should be strictly
> limited, and not pervasive.

Agreed. The "or" was meant as an exclusive-or.

cheers,
   Roland


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

[Luciano Resende]

On Sun, Jul 20, 2008 at 5:56 AM, Roland Weber <ossfwot@...> wrote:

> Hi Noel,
>
>>> * Should the user management default be Apache Directory or a
>>>  simple database?
>>
>> User management is ambiguous.  Are we talking about authentication?
>> Authorization?  And we should probably not be dependent on a particular
>> repository type.
>
> That was the only occurrence of the term that I left in the
> proposal :-) Since Apache Directory was mentioned, I found
> it unambiguous there. The real choice is of course LDAP or
> relational DB.

I see two things here :

- Someone enter the gallery as a "guest user" and have access to all
public albums and pictures.

- Someone enter the gallery, sign in as a user, and gain admin access
to all the albums owned by the user, as well as access to other public
albums and pictures.

Mapping this to some requirements :

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

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.


>
>>> * How will access control be implemented?
>>
>> TBD, and it may exist at different control points, e.g., at the business
>> logic level (container or component managed) and data store level
>> (JCR/JackRabbit).
>
> Good point.

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.

>
>>> * Will the Web service just provide data for machine to machine
>>>  exchanges or will it default to human readable?
>>
>> I doubt that the "Web service" would be in any way human readable, by
>> default or otherwise.
>
> :-)

+1

>
>>> Access control should provide the option to mark photos as public
>>> (anyone), protected (invite only), or private (just the owner).
>>> Options for managing the invites for each user are LDAP or a simple
>>> database. Permission checking can be implemented in the backend
>>> as a Jackrabbit access manager or in an application layer. Candidate
>>> technologies are JAAS and JSecurity, which both allow for pluggable
>>> authentication.
>>
>> As noted above, access control (authorization) can be handled at multiple
>> points.  The surface area related to authorization should be strictly
>> limited, and not pervasive.
>
> Agreed. The "or" was meant as an exclusive-or.
>
> cheers,
>  Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: projects-unsubscribe@...
> For additional commands, e-mail: projects-help@...
>
>

--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

[Roland Weber]

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


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

[Angela Cymbalak]

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

+1

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

+1

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

This is what I had always envisioned when stating "user
management".  Possibly a poor choice of words but the closest thing I
could come up with to what I thought needed implemented.  Perhaps we
should start calling it "friend management" instead.

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

+1


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

Could we eventually just make "friend management" pluggable?  Would
that be easier than even going the LDAP route?  I guess we have to
have a default though for those setting up a standalone system.


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

It is definitely a latter part of the project task.


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



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

[Angela Cymbalak]

> > * Will the Web service just provide data for machine to machine
> >   exchanges or will it default to human readable?
>
>I doubt that the "Web service" would be in any way human readable, by
>default or otherwise.

OK, so my documentation skills are a little rusty.  Everyone is
correct that a "Web service" would not be human readable. :-)

>[...]
> > * Should we use JCR or a (relational) Database?
>
>See prior response, but I believe that we're nominally agreed to hang our
>implementation on JCR and see how that goes.

+1

>We should not need to do so, if you're talking about a Web service.  The Web
>service client would be responsible for presentation.  What we need to
>determine is the Web service interface by which the client would interact
>with repository content.

+1

I'm still mulling over the questions that I cut out of here...

Angie



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

[Roland Weber]

Hi Angie,

> This is what I had always envisioned when stating "user management".  
> Possibly a poor choice of words but the closest thing I could come up
> with to what I thought needed implemented.  Perhaps we should start
> calling it "friend management" instead.

Fine with me :-)

>> 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.
>
> Could we eventually just make "friend management" pluggable?

For the time being, I consider the friend management
a separate component that is responsible for handling
invitations and acceptance of those. Once friendship
is established between two users, that relationship is
stored in the user management component or user repository,
however you'd like to call it. I'm suggesting to use LDAP
for the user repository, not for the friend management.
So yes, I believe that friend management is pluggable.

> Would that be easier than even going the LDAP route?

See above. If you keep the users and established friendship
relationships (groups) in the LDAP, you can use that for
authentication, and you have a place where the access manager
gets the required information from. Keeping users and groups
in different repositories doesn't sound good to me.
Using anything but LDAP to keep users means that people have
to implement authentication code for every web container but
the one(s) we choose to support out of the box.
I know how to configure WebSphere to authenticate against
almost any LDAP, but I'd have to write code to authenticate
against a database with a custom layout. I didn't check
what options Geronimo, JBoss or WebLogic provide. Maybe
somebody else can add authentication details about those?
I don't want to make a case for "just because of WebSphere".

Tomcat definitely supports authentication against a database
with quite some flexibility about the DB layout. But it
handles LDAP, DB, and JAAS mutually exclusively. So in order
to have a JAAS login with authentication against LDAP, we'll
need a JAAS login module that authenticates against LDAP.*
Still, it's better to write one JAAS login module than to
write a new authentication plugin for every web container.

cheers,
   Roland


*) Java 6 comes with JAAS login modules that authenticate
against LDAP or JNDI somewhere in the SUN-specific classes.
But the principals they instantiate are also SUN-specific
classes. The JavaDocs for JndiLoginModule indicate that
the module handles password hashing itself with only one
supported hash algorithm, so it is of limited usefuleness.
http://java.sun.com/javase/6/docs/jre/api/security/jaas/spec/index.html


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

[Luciano Resende]

My only concern with requiring LDAP is the necessary configuration
steps just to get some simple standalone gallery working. But looks
like we are considering this as a "second phase" feature, so we have
enough time to play.

On Mon, Jul 21, 2008 at 10:09 PM, Roland Weber <ossfwot@...> wrote:

> Hi Angie,
>
>> This is what I had always envisioned when stating "user management".
>>  Possibly a poor choice of words but the closest thing I could come up with
>> to what I thought needed implemented.  Perhaps we should start calling it
>> "friend management" instead.
>
> Fine with me :-)
>
>>> 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.
>>
>> Could we eventually just make "friend management" pluggable?
>
> For the time being, I consider the friend management
> a separate component that is responsible for handling
> invitations and acceptance of those. Once friendship
> is established between two users, that relationship is
> stored in the user management component or user repository,
> however you'd like to call it. I'm suggesting to use LDAP
> for the user repository, not for the friend management.
> So yes, I believe that friend management is pluggable.
>

+1 to consider the friend management a separate and plugable module.
We could also check on what is available (e.g Opensocial
implementation from Apache Shindig).

>> Would that be easier than even going the LDAP route?
>
> See above. If you keep the users and established friendship
> relationships (groups) in the LDAP, you can use that for
> authentication, and you have a place where the access manager
> gets the required information from. Keeping users and groups
> in different repositories doesn't sound good to me.
> Using anything but LDAP to keep users means that people have
> to implement authentication code for every web container but
> the one(s) we choose to support out of the box.
> I know how to configure WebSphere to authenticate against
> almost any LDAP, but I'd have to write code to authenticate
> against a database with a custom layout. I didn't check
> what options Geronimo, JBoss or WebLogic provide. Maybe
> somebody else can add authentication details about those?
> I don't want to make a case for "just because of WebSphere".
>
> Tomcat definitely supports authentication against a database
> with quite some flexibility about the DB layout. But it
> handles LDAP, DB, and JAAS mutually exclusively. So in order
> to have a JAAS login with authentication against LDAP, we'll
> need a JAAS login module that authenticates against LDAP.*
> Still, it's better to write one JAAS login module than to
> write a new authentication plugin for every web container.
>
> cheers,
>  Roland
>
>
> *) Java 6 comes with JAAS login modules that authenticate
> against LDAP or JNDI somewhere in the SUN-specific classes.
> But the principals they instantiate are also SUN-specific
> classes. The JavaDocs for JndiLoginModule indicate that
> the module handles password hashing itself with only one
> supported hash algorithm, so it is of limited usefuleness.
> http://java.sun.com/javase/6/docs/jre/api/security/jaas/spec/index.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: projects-unsubscribe@...
> For additional commands, e-mail: projects-help@...
>
>

--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/

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

[Roland Weber]

Luciano Resende wrote:
> My only concern with requiring LDAP is the necessary configuration
> steps just to get some simple standalone gallery working. But looks
> like we are considering this as a "second phase" feature, so we have
> enough time to play.

Yes, I understand that concern. I'm not sure about the
time we have to play. We need to work on the security
architecture right from the start. But I'll keep an eye
open for ways to allow for a simple setup.

cheers,
   Roland


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

[Roland Weber]

> I didn't check
> what options Geronimo, JBoss or WebLogic provide.

Geronimo handles authentication via JAAS and provides
login modules for LDAP as well as database backends.

http://cwiki.apache.org/GMOxDOC21/configuring-login-modules.html
http://cwiki.apache.org/GMOxDOC21/ldap-realm.html
http://cwiki.apache.org/GMOxDOC21/database-sql-realm.html

cheers,
   Roland


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

[Angela Cymbalak]

JBoss has a login module for LDAP
http://wiki.jboss.org/wiki/LdapLoginModule
The site
http://wiki.jboss.org/wiki/SecurityFAQ?action=e&windowstate=normal&mode=view 
implies that jdbc connections can be used.  I didn't find a link to
it directly during my quick serach:
Q11: When I change the security information in the backend store
(jdbc, ldap, etc.), why aren't the changes are not immeadiately seen?
A11: Because the security manager caches credentials by default. See
<http://wiki.jboss.org/wiki/CachingLoginCredentials>CachingLoginCredentials
for information on configuring the cache and flushing the cache.

I'll try to look up WebLogic after my next meeting.

Angie

At 02:18 AM 7/22/2008, you wrote:

>>I didn't check
>>what options Geronimo, JBoss or WebLogic provide.
>
>Geronimo handles authentication via JAAS and provides
>login modules for LDAP as well as database backends.
>
>http://cwiki.apache.org/GMOxDOC21/configuring-login-modules.html
>http://cwiki.apache.org/GMOxDOC21/ldap-realm.html
>http://cwiki.apache.org/GMOxDOC21/database-sql-realm.html
>
>cheers,
>   Roland
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: projects-unsubscribe@...
>For additional commands, e-mail: projects-help@...
>

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

[Roland Weber]

Hi Angie,

> JBoss has a login module for LDAP
> http://wiki.jboss.org/wiki/LdapLoginModule

The one for DB is documented here:
http://wiki.jboss.org/wiki/DatabaseServerLoginModule

DB layout requirements seem to be the same as for Tomcat.
And JBoss login modules are JAAS login modules:
http://www.docjar.com/docs/api/org/jboss/security/auth/spi/AbstractServerLoginModule.html

cheers,
   Roland


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

[Roland Weber]

I had a quick look on randomly selected other
application servers.

Glassfish uses JAAS, but requires login modules to
be derived from a SUN-specific class. It supports
both LDAP and JDBC, though JDBC seems to be somewhat tricky.
DB table layout looks similar to Tomcat, but Glassfish
enforces password hashing.
https://glassfish.dev.java.net/javaee5/security/faq.html#pluglogin
http://codepimpsdotorg.blogspot.com/2007/12/glassfish-jdbc-realm-authentication.html


Jetty can use JAAS, but requires login modules to
be derived from a Jetty-specific class. It has
login modules for both LDAP and JDBC.
DB table layout looks similar to Tomcat.
http://docs.codehaus.org/display/JETTY/JAAS


I am beginning to feel like a DB user repository
is not as problematic as I thought, since every
app server we checked so far, except for WebSphere,
comes with built-in support.

On the other hand, I am beginning to wonder how
useful JAAS really is for a security architecture,
if every other app server requires login modules
to be derived from a specific base class. Maybe
we can at least use additional container agnostic
JAAS modules to populate the Subject with the
information that the access manager will need.

cheers,
   Roland

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

[Angela Cymbalak]

Can we just use jSecurity and let them deal with it? :-)

Angie

At 12:36 PM 7/22/2008, Roland Weber wrote:

>I had a quick look on randomly selected other
>application servers.
>
>Glassfish uses JAAS, but requires login modules to
>be derived from a SUN-specific class. It supports
>both LDAP and JDBC, though JDBC seems to be somewhat tricky.
>DB table layout looks similar to Tomcat, but Glassfish
>enforces password hashing.
>https://glassfish.dev.java.net/javaee5/security/faq.html#pluglogin
>http://codepimpsdotorg.blogspot.com/2007/12/glassfish-jdbc-realm-authentication.html
>
>
>Jetty can use JAAS, but requires login modules to
>be derived from a Jetty-specific class. It has
>login modules for both LDAP and JDBC.
>DB table layout looks similar to Tomcat.
>http://docs.codehaus.org/display/JETTY/JAAS
>
>
>I am beginning to feel like a DB user repository
>is not as problematic as I thought, since every
>app server we checked so far, except for WebSphere,
>comes with built-in support.
>
>On the other hand, I am beginning to wonder how
>useful JAAS really is for a security architecture,
>if every other app server requires login modules
>to be derived from a specific base class. Maybe
>we can at least use additional container agnostic
>JAAS modules to populate the Subject with the
>information that the access manager will need.
>
>cheers,
>   Roland
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: projects-unsubscribe@...
>For additional commands, e-mail: projects-help@...
>

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

[Noel J. Bergman]

> Can we just use jSecurity and let them deal with it? :-)

Don't know enough about it, so ask.  Could be interesting to find out.

        --- Noel



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

[Roland Weber]

Angela Cymbalak wrote:
> Can we just use jSecurity and let them deal with it? :-)

Hum. I was almost ready to send a long post with a
general drift of "no" when I had another look at the
jSecurity JavaDocs and found their "web" packages.

http://www.jsecurity.org/api/
http://www.jsecurity.org/api/org/jsecurity/web/servlet/JSecurityFilter.html

It seems that it is possible to configure jSecurity
as a servlet filter. You can specify all the auth stuff
that you would expect to find in web.xml, like protected
paths and basic or form-based authentication and so on.
Instead of using the container security infrastructure,
you'd be relying on jSecurity. In light of this,
my answer changes to:

If you want to leverage the security infrastructure
of the web container, plugging into JAAS is the way
to go. If you don't, you can go with jSecurity alone.

I'd be very cautious to bypass container security. In
a J2EE container (rather than a simple web container),
it reaches much further than just allowing access to
a web resource or not. There is identity propagation
when calling EJBs, vendor specific integration with
single sign-on solutions, and probably more.

While I was looking at several web and J2EE containers
to get a feel for what authentication options they
provide, we don't have to tackle the full complexity
for a prototype. We can just pick one web container
(Tomcat or Geronimo) and implement the JAAS modules
for that. My idea is to plug some modules into the
JAAS authentication that populate the Subject with
one or two principals of our own. The access manager
then just checks for the presence of these principals.
One princiapl to provide user identity, the other for
querying friend relationships, that's what I'm heading
for at the moment. We'd have container specific login
modules and setup, but both the application and the
backend remain container agnostic. A standalone app
would have to perform an explicit JAAS login, but the
backend still doesn't care. If the principals are in
the Subject, it doesn't matter where they came from.

cheers,
   Roland

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