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 anyz <an...@gmail.com> on 2010/12/08 06:04:39 UTC
Recommended Security Architecture
Hi,
I am assigned a task to work on Portal based upon Portlet 2.0 that will be
deployed on Tomcat using Jetspeed 2.2.1. However in future this must be
deployable on other portlet servers like IBM WebSphere. In first step I have
to work out the possible security model for the application. Major
requirements for security:
- Based on some standard
- Easily portable to Websphere or other server
- Two step security model in which authentication is done on
cooperate network (LDAP or domain controller for example) than
authorizations will be controlled by portlet server
So security must not dependent or tightly coupled with Jetspeed specific
features. My initial understanding user must exists in portlet server
(Jetspeed on this case) to control the authorization stuff(who can access
and what can do). What could be best way these server independent so that
these can be ported easily to other servers. Or for each server we have to
re-create user/groups/roles using sort of admin interface that server
provides.
Thanks for time.
Re: Recommended Security Architecture
Posted by David Taylor <da...@gmail.com>.
As I was trying to explain, the documentation is out of sync. For
2.2.2, we should consider disabling LDAP support until the
documentation is made current again
On Sun, Dec 12, 2010 at 10:02 PM, anyz <an...@gmail.com> wrote:
> To include differnt LDAP servers we can need to write our own security layer
> using JAAS or SpringSecurity? In this case we also need to keep LDAP and
> Jetspeed synchronized as new users/groups are added/deleted. I am exploring
> but i guess for this synchronization Jetspeed will be providing APIs.
>
> Thanks
>
>
>
>
> On Mon, Dec 13, 2010 at 10:51 AM, anyz <an...@gmail.com> wrote:
>
>> David,
>> Thanks for your explainations. Just found on Jetspeed site that currently
>> it supports only following LDAP servers
>> http://portals.apache.org/jetspeed-2/components/jetspeed-security/ldap.html.
>>
>>
>> - Apache DS <http://directory.apache.org/>
>> - Open LDAP <http://www.openldap.org/>
>> - Domino <http://www-306.ibm.com/software/lotus/>
>> - Sun DS<http://www.sun.com/software/products/directory_srvr_ee/dir_srvr/index.xml>
>>
>> So i have to use one of these. It won't work with Windows Active Directory?
>>
>>
>>
>>
>>
>> On Thu, Dec 9, 2010 at 9:24 PM, David Taylor <da...@gmail.com>wrote:
>>
>>> On Tue, Dec 7, 2010 at 9:04 PM, anyz <an...@gmail.com> wrote:
>>> > Hi,
>>> >
>>> >
>>> >
>>> > I am assigned a task to work on Portal based upon Portlet 2.0 that will
>>> be
>>> > deployed on Tomcat using Jetspeed 2.2.1. However in future this must be
>>> > deployable on other portlet servers like IBM WebSphere. In first step I
>>> have
>>> > to work out the possible security model for the application. Major
>>> > requirements for security:
>>> >
>>> > - Based on some standard
>>> >
>>> > - Easily portable to Websphere or other server
>>> >
>>> > - Two step security model in which authentication is done on
>>> > cooperate network (LDAP or domain controller for example) than
>>> > authorizations will be controlled by portlet server
>>> >
>>> Be careful with Jetspeed 2.2.1 LDAP: a new LDAP impl was rewritten in
>>> 2.2, and the docs were never changed. The LDAP docs are not up-to-date
>>> -- its really irresponsible . I would not use the online docs for
>>> reference, see the code and Spring configs instead.
>>>
>>> To summarize, yes, we use our own schema for storing users. The 2.2
>>> LDAP solution has a LDAP replicator - basically you point Jetspeed at
>>> your LDAP, give it credentials and tell it which LDAP attributes to
>>> replicate and map to our schema, and it periodically synchronizes the
>>> LDAP attributes into the Jetspeed database
>>>
>>>
>>> >
>>> >
>>> > So security must not dependent or tightly coupled with Jetspeed specific
>>> > features. My initial understanding user must exists in portlet server
>>> > (Jetspeed on this case) to control the authorization stuff(who can
>>> access
>>> > and what can do). What could be best way these server independent so
>>> that
>>> > these can be ported easily to other servers. Or for each server we have
>>> to
>>> > re-create user/groups/roles using sort of admin interface that server
>>> > provides.
>>> >
>>> The LDAP solution might work for you, since you can replicate the bits
>>> you want. Jetspeed is based upon standard Java Security, JAAS, servlet
>>> declarative security. So you have lots of standard choices without
>>> needing to couple to the Jetspeed Security APIs, although that is an
>>> option too.
>>>
>>> We have written custom authentication solutions, usually following a
>>> pattern that combines a filter and jetspeed valve to populate the
>>> required Jetspeed Subject in the request, examples:
>>>
>>>
>>> http://portals.apache.org/jetspeed-2/guides/guide-tomcat-sso-cross-context-j2-realm.html
>>> http://portals.apache.org/jetspeed-2/deployguide/config-sso.html
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>>
>>>
>>
>
--
David
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Recommended Security Architecture
Posted by anyz <an...@gmail.com>.
To include differnt LDAP servers we can need to write our own security layer
using JAAS or SpringSecurity? In this case we also need to keep LDAP and
Jetspeed synchronized as new users/groups are added/deleted. I am exploring
but i guess for this synchronization Jetspeed will be providing APIs.
Thanks
On Mon, Dec 13, 2010 at 10:51 AM, anyz <an...@gmail.com> wrote:
> David,
> Thanks for your explainations. Just found on Jetspeed site that currently
> it supports only following LDAP servers
> http://portals.apache.org/jetspeed-2/components/jetspeed-security/ldap.html.
>
>
> - Apache DS <http://directory.apache.org/>
> - Open LDAP <http://www.openldap.org/>
> - Domino <http://www-306.ibm.com/software/lotus/>
> - Sun DS<http://www.sun.com/software/products/directory_srvr_ee/dir_srvr/index.xml>
>
> So i have to use one of these. It won't work with Windows Active Directory?
>
>
>
>
>
> On Thu, Dec 9, 2010 at 9:24 PM, David Taylor <da...@gmail.com>wrote:
>
>> On Tue, Dec 7, 2010 at 9:04 PM, anyz <an...@gmail.com> wrote:
>> > Hi,
>> >
>> >
>> >
>> > I am assigned a task to work on Portal based upon Portlet 2.0 that will
>> be
>> > deployed on Tomcat using Jetspeed 2.2.1. However in future this must be
>> > deployable on other portlet servers like IBM WebSphere. In first step I
>> have
>> > to work out the possible security model for the application. Major
>> > requirements for security:
>> >
>> > - Based on some standard
>> >
>> > - Easily portable to Websphere or other server
>> >
>> > - Two step security model in which authentication is done on
>> > cooperate network (LDAP or domain controller for example) than
>> > authorizations will be controlled by portlet server
>> >
>> Be careful with Jetspeed 2.2.1 LDAP: a new LDAP impl was rewritten in
>> 2.2, and the docs were never changed. The LDAP docs are not up-to-date
>> -- its really irresponsible . I would not use the online docs for
>> reference, see the code and Spring configs instead.
>>
>> To summarize, yes, we use our own schema for storing users. The 2.2
>> LDAP solution has a LDAP replicator - basically you point Jetspeed at
>> your LDAP, give it credentials and tell it which LDAP attributes to
>> replicate and map to our schema, and it periodically synchronizes the
>> LDAP attributes into the Jetspeed database
>>
>>
>> >
>> >
>> > So security must not dependent or tightly coupled with Jetspeed specific
>> > features. My initial understanding user must exists in portlet server
>> > (Jetspeed on this case) to control the authorization stuff(who can
>> access
>> > and what can do). What could be best way these server independent so
>> that
>> > these can be ported easily to other servers. Or for each server we have
>> to
>> > re-create user/groups/roles using sort of admin interface that server
>> > provides.
>> >
>> The LDAP solution might work for you, since you can replicate the bits
>> you want. Jetspeed is based upon standard Java Security, JAAS, servlet
>> declarative security. So you have lots of standard choices without
>> needing to couple to the Jetspeed Security APIs, although that is an
>> option too.
>>
>> We have written custom authentication solutions, usually following a
>> pattern that combines a filter and jetspeed valve to populate the
>> required Jetspeed Subject in the request, examples:
>>
>>
>> http://portals.apache.org/jetspeed-2/guides/guide-tomcat-sso-cross-context-j2-realm.html
>> http://portals.apache.org/jetspeed-2/deployguide/config-sso.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>
Re: Recommended Security Architecture
Posted by anyz <an...@gmail.com>.
David,
Thanks for your explainations. Just found on Jetspeed site that currently it
supports only following LDAP servers
http://portals.apache.org/jetspeed-2/components/jetspeed-security/ldap.html.
- Apache DS <http://directory.apache.org/>
- Open LDAP <http://www.openldap.org/>
- Domino <http://www-306.ibm.com/software/lotus/>
- Sun DS<http://www.sun.com/software/products/directory_srvr_ee/dir_srvr/index.xml>
So i have to use one of these. It won't work with Windows Active Directory?
On Thu, Dec 9, 2010 at 9:24 PM, David Taylor <da...@gmail.com>wrote:
> On Tue, Dec 7, 2010 at 9:04 PM, anyz <an...@gmail.com> wrote:
> > Hi,
> >
> >
> >
> > I am assigned a task to work on Portal based upon Portlet 2.0 that will
> be
> > deployed on Tomcat using Jetspeed 2.2.1. However in future this must be
> > deployable on other portlet servers like IBM WebSphere. In first step I
> have
> > to work out the possible security model for the application. Major
> > requirements for security:
> >
> > - Based on some standard
> >
> > - Easily portable to Websphere or other server
> >
> > - Two step security model in which authentication is done on
> > cooperate network (LDAP or domain controller for example) than
> > authorizations will be controlled by portlet server
> >
> Be careful with Jetspeed 2.2.1 LDAP: a new LDAP impl was rewritten in
> 2.2, and the docs were never changed. The LDAP docs are not up-to-date
> -- its really irresponsible . I would not use the online docs for
> reference, see the code and Spring configs instead.
>
> To summarize, yes, we use our own schema for storing users. The 2.2
> LDAP solution has a LDAP replicator - basically you point Jetspeed at
> your LDAP, give it credentials and tell it which LDAP attributes to
> replicate and map to our schema, and it periodically synchronizes the
> LDAP attributes into the Jetspeed database
>
>
> >
> >
> > So security must not dependent or tightly coupled with Jetspeed specific
> > features. My initial understanding user must exists in portlet server
> > (Jetspeed on this case) to control the authorization stuff(who can access
> > and what can do). What could be best way these server independent so that
> > these can be ported easily to other servers. Or for each server we have
> to
> > re-create user/groups/roles using sort of admin interface that server
> > provides.
> >
> The LDAP solution might work for you, since you can replicate the bits
> you want. Jetspeed is based upon standard Java Security, JAAS, servlet
> declarative security. So you have lots of standard choices without
> needing to couple to the Jetspeed Security APIs, although that is an
> option too.
>
> We have written custom authentication solutions, usually following a
> pattern that combines a filter and jetspeed valve to populate the
> required Jetspeed Subject in the request, examples:
>
>
> http://portals.apache.org/jetspeed-2/guides/guide-tomcat-sso-cross-context-j2-realm.html
> http://portals.apache.org/jetspeed-2/deployguide/config-sso.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
Re: Recommended Security Architecture
Posted by David Taylor <da...@gmail.com>.
On Tue, Dec 7, 2010 at 9:04 PM, anyz <an...@gmail.com> wrote:
> Hi,
>
>
>
> I am assigned a task to work on Portal based upon Portlet 2.0 that will be
> deployed on Tomcat using Jetspeed 2.2.1. However in future this must be
> deployable on other portlet servers like IBM WebSphere. In first step I have
> to work out the possible security model for the application. Major
> requirements for security:
>
> - Based on some standard
>
> - Easily portable to Websphere or other server
>
> - Two step security model in which authentication is done on
> cooperate network (LDAP or domain controller for example) than
> authorizations will be controlled by portlet server
>
Be careful with Jetspeed 2.2.1 LDAP: a new LDAP impl was rewritten in
2.2, and the docs were never changed. The LDAP docs are not up-to-date
-- its really irresponsible . I would not use the online docs for
reference, see the code and Spring configs instead.
To summarize, yes, we use our own schema for storing users. The 2.2
LDAP solution has a LDAP replicator - basically you point Jetspeed at
your LDAP, give it credentials and tell it which LDAP attributes to
replicate and map to our schema, and it periodically synchronizes the
LDAP attributes into the Jetspeed database
>
>
> So security must not dependent or tightly coupled with Jetspeed specific
> features. My initial understanding user must exists in portlet server
> (Jetspeed on this case) to control the authorization stuff(who can access
> and what can do). What could be best way these server independent so that
> these can be ported easily to other servers. Or for each server we have to
> re-create user/groups/roles using sort of admin interface that server
> provides.
>
The LDAP solution might work for you, since you can replicate the bits
you want. Jetspeed is based upon standard Java Security, JAAS, servlet
declarative security. So you have lots of standard choices without
needing to couple to the Jetspeed Security APIs, although that is an
option too.
We have written custom authentication solutions, usually following a
pattern that combines a filter and jetspeed valve to populate the
required Jetspeed Subject in the request, examples:
http://portals.apache.org/jetspeed-2/guides/guide-tomcat-sso-cross-context-j2-realm.html
http://portals.apache.org/jetspeed-2/deployguide/config-sso.html
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org