re: authentication

["Manganotti Francesco (USI)" <Fr...@usi.unicredit.it>]

Anyone knows a good way to implement AUTHORIZATION with Struts.

cheers,
F.
Questo messaggio di posta elettronica contiene informazioni di carattere confidenziale rivolte esclusivamente al destinatario sopra indicato.
E' vietato l'uso, la diffusione, distribuzione o riproduzione da parte di ogni altra persona. Nel caso aveste ricevuto questo messaggio di posta elettronica per errore, siete pregati di segnalarlo immediatamente al mittente e distruggere quanto ricevuto (compresi i file allegati) senza farne copia.
Qualsivoglia utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione dell'obbligo di non prendere cognizione della corrispondenza tra altri soggetti, salvo più grave illecito, ed espone il responsabile alle relative conseguenze.

Confidentially notice. This e-mail transmission may contain legally privileged and/or confidential information. Please do not read it if you are not the intended recipient(S).
Any use, distribution, reproduction or disclosure by any other person is strictly prohibited.
If you have received this e-mail in error, please notify the sender and destroy the original transmission and its attachments without reading or saving it in any manner.

Re: authentication

[Max Cooper <ma...@maxcooper.com>]

Use container-managed security, or this filter-based clone, for which I am
the project leader: http://securityfilter.sourceforge.net/. The Servlet spec
contains the information needed to get started with container-managed
security. Your app server documentation will have information about how to
configure realms. It may seem complicated at first, but it is much easier
than writing your own system.

If you organize your action paths by what role they require, you can just
use security-constraints and url-patterns to protect everything:

/admin/* limited to users with the 'admin' role
/order/* limited to users with the 'customer', 'sales', or 'admin' roles
... etc.

If that is the case, that is all you need to do.


Or you can protect everything with a security-constraint and / url-pattern.
Then add a set of roles that will cover your entire user base. For instance,
if every user has the 'admin' role OR the 'customer' role OR the 'sales'
role, just add that set of roles to the security-constraint so everyone can
get to everything after they login. The reason to protect everything like
this is so that the container will authenticate users automatically when
they make a request for any of these resources. You will add the real
protection for individual actions (using roles) in struts-config.xml later.

NOTE: You may also need to un-protect url-patterns like /images/* so that
the images will display properly on your login form. You can do that by
creating a security-constraint with the /images/* (and /styles/*, etc. -- 
whatever should be publicly accessible) url-pattern and don't assign any
roles to it.

Now that you have the container doing the authentication for your whole app,
you will want to limit which users can execute a given action by assigning a
role (or roles) to each action in Struts. You can do that by specifying a
roles attribute in an action-mapping:
    <action-mappings>        <action            path="/editOrder"
type="my.package.EditOrderAction"            name="orderForm"
scope="request"            input="/editOrder.jsp"
roles="admin,sales"        />    </action-mappings>The roles="admin,sales"
attribute here means that users with either the 'admin' or 'sales' role (or
both) will be allowed to execute this action.

See my posts in the recent "Verifying integrity of URLs" thread for some
ideas on how to do programmatic security when the roles are not specific
enough to decide if a user should be able to execute the action or not (e.g.
a customer can only see their orders, but not orders for other users).

That is a basic overview of how to do Struts security with container-managed
security (or a filter-based clone of container-managed security like
SecurityFilter). I am a big proponent of using as much standard security
stuff as you can (container-managed, or a filter that is a clone of it)
because it is easier to implement, generally more secure, generally works
better (automatic, just-in-time authentication), and gets along better with
other things (like the Struts roles= attribute) than writing your own.
Everyone should learn how the container-managed security stuff works before
making the decision of what to use for their app. At the very least, there
are some useful patterns and behaviors in the standard that will help in
writing your own system. Sometimes it still makes to write your own
security, but I think we as developers have a tendency to skip over
container-managed security before investigating how it could work for us and
go right into writing our own stuff. Most of the time, it would be a lot
less work and our apps would work a lot better if we just took the time to
learn the standard. I am guilty of skipping it over in the past, but it is
very clear to me now that learning the standard first is the best approach,
even if you don't end up using it directly.

-Max

----- Original Message ----- 
From: "Manganotti Francesco (USI)" <Fr...@usi.unicredit.it>
To: "Struts Users Mailing List (E-mail)" <st...@jakarta.apache.org>
Sent: Monday, October 06, 2003 12:41 AM
Subject: re: authentication


Anyone knows a good way to implement AUTHORIZATION with Struts.

cheers,
F.
Questo messaggio di posta elettronica contiene informazioni di carattere
confidenziale rivolte esclusivamente al destinatario sopra indicato.
E' vietato l'uso, la diffusione, distribuzione o riproduzione da parte di
ogni altra persona. Nel caso aveste ricevuto questo messaggio di posta
elettronica per errore, siete pregati di segnalarlo immediatamente al
mittente e distruggere quanto ricevuto (compresi i file allegati) senza
farne copia.
Qualsivoglia utilizzo non autorizzato del contenuto di questo messaggio
costituisce violazione dell'obbligo di non prendere cognizione della
corrispondenza tra altri soggetti, salvo più grave illecito, ed espone il
responsabile alle relative conseguenze.

Confidentially notice. This e-mail transmission may contain legally
privileged and/or confidential information. Please do not read it if you are
not the intended recipient(S).
Any use, distribution, reproduction or disclosure by any other person is
strictly prohibited.
If you have received this e-mail in error, please notify the sender and
destroy the original transmission and its attachments without reading or
saving it in any manner.



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org