You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Alex McLintock <al...@OWAL.co.uk> on 2001/04/01 15:08:30 UTC

Re: Multiaplication authentication system with Jetspeed

At 16:30 30/03/01, carlos beltran wrote:
>Hi All,
>
>We have now running different web applications with jetspeed, others
>with Jive, and others that are running alone but that we intent to make
>it work with turbine... and we would like to implement a common
>authentication system for all the applications.


I have the same problem since I am running Jyve and Jetspeed on my
SF/Computing book reviews site www.DiverseBooks.com
(Another live example of Jetspeed)


In theory this should be easy since the Turbine authentication system is 
"pluggable"
you could replace it with something else... - eg a LDAP solution perhaps...
Unfortunately I have never tried this so can't confirm how easy it is.

I avoided the issue by removing the ability for users to log in to Jetspeed
but that's not a very good solution of course. I need to solve it soon.

I see that the first problem would be to update Jyve to the latest version 
of Turbine.
This shouldn't be too hard but I have hardly looked at the latest Turbine 
code for nearly
six months and so would need significant hand holding to update it (plus I am
not a committer so it would take longer than hoped.) Besides I don't want 
even more
on my plate.


=======================

PS Any Turbine experts know about the mail classes from Sun and how we use 
them?
Do we still have problems with mail servers not on "localhost"?

Alex McLintock



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


Re: Multiaplication authentication system with Jetspeed

Posted by Santiago Gala <sg...@hisitech.com>.
Alex McLintock wrote:

> At 16:30 30/03/01, carlos beltran wrote:
> 
>> Hi All,
>> 
>> We have now running different web applications with jetspeed, others
>> with Jive, and others that are running alone but that we intent to make
>> it work with turbine... and we would like to implement a common
>> authentication system for all the applications.
> 
> 
> 
> I have the same problem since I am running Jyve and Jetspeed on my
> SF/Computing book reviews site www.DiverseBooks.com
> (Another live example of Jetspeed)
> 

I added it in the xdocs. It will eventually arrive to the jakarta public 
site. Thanks for using it!

I just visited it and it look very cool. The idea of linking RSS 
channels with jyve screens is good. I imagine the channels will auto 
generate from the database.

Do you have it to the level where it could be abstracted into a 
DBRSSPortlet, which would generate a RSS Channel given jdbc parameters 
and then process it?

Parameterizing it like jdbcurl, user, password, table, urlfield, 
titlefield, descfield, and a global description/title/url, it could be 
used for a lot of things


> 
> In theory this should be easy since the Turbine authentication system is 
> "pluggable"
> you could replace it with something else... - eg a LDAP solution perhaps...
> Unfortunately I have never tried this so can't confirm how easy it is.
> 

Turbine has already a contributed LDAP solution (not finished, I think). 
This could be enough for certain applications.

When implementing Jetspeed security it is very important to distinguish 
two different use cases:

- simple portals, where the admin/deployers controls the whole environment
- enterprise sites, where enterprise policies and different concerns are 
at stake.

While a solution like a Jetspeed based LDAP one can fit in the first use 
case, for enterprise systems we will have to let the container 
authenticate, and use some solution that allows for distributed 
authentication (ejb, other corporate apps, etc.) This could be achieved 
by having a LDAP or JAAS turbine security implementation, or (I think 
much better) having Turbine pick up authentication info from the servlet 
container, and pushing the task down to the container level.


> I avoided the issue by removing the ability for users to log in to Jetspeed
> but that's not a very good solution of course. I need to solve it soon.
> 
> I see that the first problem would be to update Jyve to the latest 
> version of Turbine.
> This shouldn't be too hard but I have hardly looked at the latest 
> Turbine code for nearly
> six months and so would need significant hand holding to update it (plus 
> I am
> not a committer so it would take longer than hoped.) Besides I don't 
> want even more
> on my plate.
> 

That goes on with most of us. Security code in turbine has been 
significantly updated in the last months (including a contributed LDAP 
implementation just starting), so the task will not be as difficult as 
it looks.

On the other hand, here at jetspeed we are adopting the norm to updating 
turbine at tdk alpha releases (about once a month), so that we have a 
stable turbine base for maintenance. Take this into account in any 
updating plans.


> 
> =======================
> 
> PS Any Turbine experts know about the mail classes from Sun and how we 
> use them?
> Do we still have problems with mail servers not on "localhost"?
> 

I think the main problem with mail servers not on "localhost" is that 
they will refuse to relay mail sent from your jetspeed machine unless 
you configure them to accept it, but I could be wrong.


> Alex McLintock
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org



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