cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianluca Sartori <g.sart...@elis.org>
Subject RE: Authentication and Autorization
Date Wed, 10 Dec 2003 08:04:35 GMT
Il mar, 2003-12-09 alle 16:51, Ralph Goers ha scritto:
> You should investigate the authentication framework block before you go too
> far down the road.  It provides much of the functionality you are looking
> for. 

Our authentication/authorization system implements a single-sign-on on
multiple sites/domains, much like the Microsoft Passport. I'm going to
have a look at the cocoon authentication framework, but I need a way to
extend it integrating my "client" library. There are some SOAP calls,
but this shouldn't be a problem.

> We have just completed integrating Cocoon's authorization framework
> with JAAS and had to write to components to do it.

We are using JAAS too on the "authentication server" side. What I need
to integrate with cocoon is the "client side" of the system. Actually I
don't want to let the site runing cocoon do the authentication itself,
but only communicate with an authentication server (which, anyway, is
not so different architecturally speaking). I don't think coccon can do
this (the protool is unknow to coccon), but if there's a way to extend
the framework I'll be glad if you could point me to some documentation.

> The first component is
> authentication generator to perform the authentication and return the
> required XML to the framework, along with the data to be associated with the
> user. The generator creates an object which actually performs the
> authentication. This object is saved in the session for later use. 

So I use a generator to get User info. Then with the PermissionSelector
I can decide what to do. Uhmm, This means I must redirect to different
pages depending on permission owned by the user? (stupid question, I
know, but I'm still studying cocoon, it's a big beast...). Sometimes it
is useful to move the logic from the sitemap into the page and take
decision in there instead of having multiple pages for each user type.
Or at least, this is what I've done till now. Probably is not so
different, anyway.

> The second component is a PermissionSelector which is very similar to the
> ExceptionSelector. When configuring the selector you define the permissions
> that can be checked and then the selector actually checks to see if the end
> user has the requested permission. The selector uses the object saved in the
> session by the generator to do the permission check.

I'll check. Could you point me to some documentation if it exists?


Thanks for all,
Gianluca
> 
> 
> Ralph
> 
> > -----Original Message-----
> > From: Gianluca Sartori [mailto:g.sartori@elis.org]
> > Sent: Tuesday, December 09, 2003 7:08 AM
> > To: users@cocoon.apache.org
> > Subject: Authentication and Autorization
> > 
> > 
> > Hi all,
> > 
> > 	I'm adapting an authentication/authorization system we 
> > are using within
> > normal JSP/servet pages. It consists of a simple class which must be
> > instantiated at the beginning of the page. It knows where to redirect
> > the user for authentication and within the JSP/Servlet you can use its
> > methods to get user information such as the username, fullname,
> > telephone, etc.
> > 
> > What's the best place to incapsulate the funcionalities 
> > provided by this
> > class? I'm buiding an action for authentication purposes and I plan to
> > develop a logicsheet to incapsulate authorization primitives so I can
> > declaratively decide whether to make available some data or not
> > depending on the current user role.
> > 
> > Is this the way to go? I thought about incapsulate my class into an
> > action, but this way I don't know how to take authorization decisions.
> > For example I need one "edit" link if the user has the "Editors" role,
> > but none if s/he has the "User" role. I don't want to create two
> > different pages for this.
> > 
> > Any help?
> > 
> > Thanks,
> > Gianluca
> > 
> > -- 
> > Gianluca Sartori                     ELIS - SIE - Software Development
> > 
> > Via Sandro Sandri, 81                         (tel) +39 06.43.56.03.55
> > 00159 Rome - Italy                            (fax) +39 06.43.56.03.99
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
-- 
Gianluca Sartori                     ELIS - SIE - Software Development

Via Sandro Sandri, 81                         (tel) +39 06.43.56.03.55
00159 Rome - Italy                            (fax) +39 06.43.56.03.99



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message