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.
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?
Thoughts and feedback would be very helpful!!
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
