On Jul 11, 2007, at 11:28 AM, Joe Bohn wrote:
Paul McMahan wrote:
There is some experimental work in sandbox/portals for an admin
console that supports dynamic extensions. One thing that it
currently lacks is security, and I am wondering if these recent
security improvements that David has made might affect how that
can be implemented.
This experimental admin console uses pluto 1.2 for a portal
container. Pluto provides a "driver" webapp that is responsible
for creating the portal pages. First you deploy the driver webapp
and when you want to add new portlets to your portal you deploy
them in separate webapps and register their context roots with the
driver. Then HTTP requests for portal pages are received by the
driver and it uses cross context dispatch to route the request to
the appropriate portlets and assemble their HTML into a page.
It seems like the most straight forward way to implement security
for this type of configuration would be to add the security
constraints to the driver webapp since it is a "choke point" for
all HTTP requests thru the portal. But this approach has at least
two problems:
- it leaves the portlet webapps unprotected from direct HTTP
access since they are deployed in separate webapps
- it doesn't allow portlet webapps to define their own customized
security constraints, or to choose not to implement security at all.
Is this second point really desirable? What would be the practical
result of allowing a portlet to define it's own security or none at
all when included with the geronimo web console? I think that most
users would expect single-signon for the Geronimo web console. IMO
it would be really annoying to be prompted for additional
credentials when accessing a particular portlet once I've already
authenticated. If we are successful and have a lot of plugins with
console extensions then it might also become a problem to have many
different credentials to manage.
I doubt the second is actually desirable.
To address the first problem we might be able to do something like :
https://issues.apache.org/jira/browse/GERONIMO-973
where portlet webapps map the driver's security contraints into
their web.xml. But that's not very flexible since it requires the
portlet webapps to keep their security settings in synch with the
driver. And if they contain servlets like DWR then those have to
be dispatched through the driver as well. I'm also wondering if
that approach actually works across separately deployed modules
(it worked for webapps deployed inside the same EAR). But even if
we can work through all that I'm still hoping that our solution
can also address the second problem, since that would make the
portal available for general purpose use and not just as an
extensible admin console.
I like the idea of a general use portal. Perhaps we could have it
both ways?
1) To integrate with the Geronimo web console you must have your
portlets conform to some security and other standards. Part of
that would involve some standard Geronimo web console practices so
that this can be integrated under a single geronimo admin
authorization. Other parts might be necessary to link/protect the
portlet context, insert content in the appropriate place for
navigation, specify a navigation icon, utilize the Geronimo skin/
style sheets, etc....
2) If this portlet application does not include the necessary
"glue" to be included in the console then it could be deployed and
accessed as any other portlet might be deployed/accessed.
That might not make sense or be practical to implement but if it is
possible it would provide some flexibility for the user and
consistency for the geronimo web console. thoughts?
So maybe there is some way to configure the security for this
portal so that the driver has no security constraints at all by
default, and instead the security constraints can be defined by
the portlet webapps in ad hoc fashion. When the driver receives
an HTTP request there needs to be some way of collecting the
credentials necessary to access all the portlets in the page and
then do the cross context dispatches as usual. The questions that
arise are:
1.) how can the driver figure out what credentials will be
necessary to successfully perform a cross context dispatch to a
given portlet webapp?
2.) how can the driver prompt the user for credentials, or (even
better) delegate that responsibility to the portlet webapp?
ideally the portlet webapps could configure their security in
geronimo-web.xml and web.xml in whatever manner they like (FORM,
BASIC, DIGEST, etc)
3.) can/should the driver perform the login or should it pass
along the necessary credentials in the dispatched request and let
the portlet webapp handle its own login?
I think you may be confusing authentication and authorization to some
extent. I think that for now requiring someone to log in before they
can use the admin console at all is appropriate. Their identity then
determines what they can do.
At some time we may want to consider some kind of "role change"
system but I really don't think this is the time. However I'm happy
to discuss it but lets start a new thread.
Thoughts and feedback would be very helpful!!
I think the best way to approach this is to use an actual portal
(jetspeed) which has a sophisticated system of portal permissions to
go along with the web permissions from the servlet spec and portlet
permissions from the portlet spec. I really don't want to get
involved in turning pluto into jetspeed.
I demonstrated some time ago that it's fairly easy to support
jetspeed portal permissions through jacc.
thanks
david jencks
Best wishes,
Paul
On Jul 10, 2007, at 11:37 AM, David Jencks wrote:
I've committed this in rev 554977. Please speak up if you have
comments or objections or encounter problems.
thanks
david jencks
On Jul 10, 2007, at 1:52 AM, David Jencks wrote:
So its a year and a half later.... I've finally made a bit of
progress on the first of these goals.
Recently I replaced the only use of remote login with login over
the openejb protocol. This means that the client/server-side
distinction is no longer relevant, and the login module wrapping
a set of login modules is not needed either.
I've refactored the authentication stuff so that:
- we still have a GeronimoLoginConfiguration
- we can still (optionally) wrap principals to determine exactly
which login module and realm they came from
- all authentication happens in a single vm, no sneaky remoting
stuff
- we use the LoginContext to create the login modules directly
from the AppConfigurationEntry[]
- registering and unregistering the subject and inserting the
identification principal is done by a login module automatically
added by the GenericSecurityRealm, rather than the
JaasSecuritySession
This eliminates most of the hard to understand code including:
JaasLoginCoordinator
JaasSecuritySession
JaasLoginService
I've also removed the subject carrying protocol and the remoting
jmx code since it isn't used.
I'm somewhat sorry to see all this sophisticated code Alan wrote
go since it is a quite interesting solution to the problem of
how to share authentication between a client and server, but I
think it has proven to be fatally complex and not really a good
solution to the original problem. As we discussed at this
apachecon security assertions seem to provide a better framework
for thinking about these questions.
I opened GERONIMO-3303 about this and expect to be comitting
after just a bit more cleanup.
thanks
david jencks
On Dec 23, 2005, at 6:37 PM, David Jencks wrote:
At ApacheCon several of us got together to discuss security in
Geronimo. These are my recollections, please expand/contradict/
modify what I forgot or got wrong.
People: Alan Cabrera, David Jencks, Kresten Krab Thorup, Hiram
Chirino, Simon Godik (Others ???)
Problems with the current implementation:
- Distinction between client-side and server-side login modules
is too hard to understand and too ad-hoc: security assertions
are a better, standard, and more comprehensible way of getting
the same functionality.
- The LoginModule wrapping a set of login modules serves little
purpose.
Things we like and want to generalize somehow:
- We'd like to extend the variety of approaches represented in
the CORBA csiv2 model to other transports and contexts beyond
CORBA
How we might get there:
Simon gave us some hints about SAML and XACML and IIUC pointed
out that most of the basic ideas we need are worked out in
detail in these specs and that we can implement these ideas
without necessarily relying on the xml-centered implementation
called for in the specs. In particular SAML extensively
discusses security assertions which are a more powerful and
systematic way of dealing with both the client/server login
module problems and the information dealt with by csiv2. My
current and very limited understanding is that SAML indicates
what kind of security assertions can be made and how to
transfer them between systems. XACML provides a framework in
which (among many many other things) these security assertions
can have effects on authentication and authorization decisions
Since ApacheCon I've started looking into XACML and SAML a tiny
bit and although I am not thrilled by the pointy brackets I
think this is an avenue we should investigate thoroughly. I
think it can definitely provide the flexibility we want in the
security model: I think the challenge will be making the
configuration comprehensible and the implementation fast. From
my very brief study it looks like XACML will provide a
framework in which authorization rules that include the request
info provided by JACC can be evaluated. I'm not sure what else
it will bring us :-)
Many thanks,
david jencks
