Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: JSR 168, Security, and User Information
Date: Thu, 14 Aug 2003 23:01:41 -0400
Message-ID: 
 <9CBB0860339F524AB4ABCB759883629801B9C2E3@j9postoffice.j9.root2k.local>
Thread-Topic: JSR 168, Security, and User Information
Thread-Index: AcNi109blOztY4fwTNCxIx11ZQFRmAAAHSjA
From: "Fletcher, Boyd C. J9C534" <Boyd.Fletcher@je.jfcom.mil>
To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>,
	"Alejandro Abdelnur" <Alejandro.Abdelnur@Sun.COM>
Cc: <jsr-168-comments@jcp.org>

Isn't this basically what SAML was suppose to fix.  We've used SAML
enabled Netegrity Siteminder and Oblix NetPoint in the past to handle
inter-app/web-server authentication and authorization. There are also a
couple of open source projects that are tackling the issue:
http://shibboleth.internet2.edu, http://www.opensaml.org, and
http://www.nsf-middleware.org/NMIR3/components/edit-software.asp

boyd


> -----Original Message-----
> From: Jeff Linwood [mailto:jeff@greenninja.com]=20
> Sent: Thursday, August 14, 2003 10:44 PM
> To: Alejandro Abdelnur
> Cc: jetspeed-dev@jakarta.apache.org; jsr-168-comments@jcp.org
> Subject: Re: JSR 168, Security, and User Information
>=20
>=20
> Hi,
>=20
> I saw JSR 196, but that looks like it will just standardize the=20
> username/password authentication for J2EE containers.  What I was=20
> looking for was a standard API for permissions (like JSR 115),=20
> username/password, single sign-on, and user information,=20
> because those=20
> are all likely to be stored in one central database.
>=20
> I agree that the container should fetch the user information, but=20
> considering that each container will have to do this, it should be=20
> standardized.  Obviously, the specification shouldn't try to specify=20
> what fields are on a user, because that won't be generic=20
> enough, but it=20
> would be nice to have one layer to integrate with for authentication,=20
> authorization, and user information.
>=20
> I would like to see single-sign on taken into account as=20
> well, because=20
> the username and password recieved from the portal container=20
> may not be=20
> the username and password required by the portlet to authenticate to=20
> another legacy system - which means that each portlet would have to=20
> store the single sign-on information as a preference.  This could be=20
> difficult to administer/automate, especially for application=20
> migrations=20
> into a portal environment.
>=20
> Thanks,
> Jeff
>=20
> Alejandro Abdelnur wrote:
> > Jeff,
> >=20
> > Thanks for your feedback.
> >=20
> > On authentication, if I understand correctly what you are proposing,
> > this is outside of the realm of portlet-apps, web-apps and=20
> > enterprise-apps. It is something it is outside of the scope=20
> of a single=20
> > container, it has to be solved in a general way (servlet-container,=20
> > ejb-container, portlet-container). Today many=20
> implementations provide=20
> > support for plugin an authentication service. Some of them=20
> are based on=20
> > JAAS and some on proprietary APIs. It's the container=20
> implementor who=20
> > has to take care of this, not the application developers.=20
> There is a=20
> > JSR, 196, that is aimed at this. Another one, JSR115, takes care of=20
> > plugglable authorization (roles checking).
> >=20
> > On user information, JSR168 puts the responsibility on the=20
> container=20
> > to
> > fetch user information data. Portlet applications don't=20
> have to worry=20
> > about this. You  cannot modify it through the Portlet API.=20
> In fact, user=20
> > information, should be another API altogether, we added this simple=20
> > mechanism to fetch user info data because portlets use it=20
> often and we=20
> > wanted to address this somehow. You can see the user info=20
> portlet API=20
> > offers as a temporary fix for something should be be addressed in a=20
> > generic way (to be usable from other component APIs).
> >=20
> > Regards.
> >=20
> > Alejandro / Stefan
> > JSR168, specification co-leads
> >=20
> > On Thursday, August 14, 2003, at 12:30  AM, Jeff Linwood wrote:
> >=20
> >> I wanted to see what people thought about the security and user
> >> information side of JSR 168.
> >>
> >> It looks like the portal security model is based on the servlet
> >> security model.  Each servlet engine has a different interface for=20
> >> plugging in a custom authentication mechanism (Tomcat's=20
> realms, for=20
> >> instance).  This means that to support multiple app=20
> servers with one=20
> >> back-end authentication database or application, multiple=20
> integration=20
> >> pieces are needed, and applications can't be deployed on any app=20
> >> server without a migration effort.  I'd prefer adding a=20
> >> security/authentication layer to the portal container=20
> specification=20
> >> that allowed different portable back ends.
> >>
> >> Otherwise, it looks like to implement an integration between my
> >> portlet and my user database, I'd have to:
> >>
> >> a) write a database integration implementation for each servlet=20
> >> engine
> >> b) write an integration between my portal container and my=20
> database to=20
> >> get the user information
> >> c) include hooks in my portlet to somehow get the database=20
> >> configuration information (say a JDBC URL, or a WSDL URL=20
> w/ username=20
> >> and password) from the portal container, and then make=20
> calls to it to=20
> >> get any additional information, or to change anything, in=20
> case we had=20
> >> one database, but multiple portal containers that don't share=20
> >> preferences for different parts of the organization.
> >>
> >> Something else I noticed with the user information model is that it
> >> doesn't look like preferences are tied to the user=20
> information that=20
> >> portal containers are supposed to pass to the portlet - so you=20
> >> couldn't write a portlet that would conform to the spec that could=20
> >> modify user information, such as email, password, etc.
> >>
> >> Anyway, let me know if these are valid issues, or if there is
> >> something I missed in the portlet specification.
> >>
> >> Thanks,
> >> Jeff Linwood
> >>
> >>
> >=20
> >=20
> >=20
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>=20
>=20