You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2007/07/10 07:52:01 UTC
Re: Geronimo Security plans (from ApacheCon)
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
>
Re: Geronimo Security plans (from ApacheCon)
Posted by Paul McMahan <pa...@gmail.com>.
On Jul 11, 2007, at 12:35 PM, David Jencks wrote:
>>> 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.
yes, admin console functions require login. The admin portlets are
bundled together in a WAR that will have the appropriate security
constraints defined in its web.xml. The question I meant to pose is
really not whether the admin console requires login but whether or
not its necessary to also "promote" its security constraints and the
corresponding deployment verbiage up to the driver webapp, since it
actually handles the portal page requests. The side effect of doing
that is that *all* portlet webapps serviced by the driver will be
subject to those constraints, not just the admin console. That
makes it impractical to use the driver for general purpose portlet
webapps.
> 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.
I'm not proposing that we implement a new security feature or a role
change system. Looking at your commit I was just too dense to
understand whether or not you had already implemented what would be
needed. From your reaction it seems that more work and investigation
would be needed.
> 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.
I agree that pluto is not intended to be an enterprise class portal
and that it doesn't make much sense to try to make it one when
liferay and jetspeed are already available. For the admin console
we're using pluto because its more consumable and provides what we
need. My goal here has been to explore the possibility of also
exposing the admin console's portal container for general purpose
use, hoping that it could provide 80% of what's needed for simple
portal apps. But I'm starting to let go of that idea since it seems
that basic JEE security doesn't quite provide what is needed.
Best wishes,
Paul
Re: Geronimo Security plans (from ApacheCon)
Posted by David Jencks <da...@yahoo.com>.
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
>>>>>
>>>>
>>>
Re: Geronimo Security plans (from ApacheCon)
Posted by Paul McMahan <pa...@gmail.com>.
On Jul 11, 2007, at 11:28 AM, Joe Bohn wrote:
>> - 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.
Good point. I agree that if the user only intends to extend the
admin console then they probably don't want to (or maybe even
shouldn't be allowed to) customize the security constraints for their
portlets. This second point was actually meant to underscore the
usage of pluto as a general purpose portal container in geronimo vs.
a portal container that is focused solely on administration
functions. When you broaden the scope to providing a general purpose
portal container I think the need for customizable security
constraints arises.
>> 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....
agreed that establishing some new standards might be necessary. for
security I hope that we can leverage the existing portlet and jee
standards in such a way that :
- adding admin portlets that want to piggyback on the admin console's
existing security configuration is easy and straightforward.
something like : "add this small chunk to your web.xml" would be ideal.
- we don't get in the way or over complicate the use of the portal
for general purpose (non-admin) portlets, recognizing here that
general purpose portlet may require custom security or none at all.
> 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?
yes I think that's the idea. The key is to implement security such
that the pluto driver delegates as much of the security handling to
the portlet webapps as possible. That may be difficult since the
driver is ultimately responsible for servicing the HTTP request, and
it operates at the level where security constraints are typically
enforced. If we would need to write a bunch of extra code or,
worse, expect the app to then I would back off the general use portal
idea for now and just focus on using pluto for an extensible admin
console.
Best wishes,
Paul
Re: Geronimo Security plans (from ApacheCon)
Posted by Joe Bohn <jo...@earthlink.net>.
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
>>>>
>>>
>>
>
>
Re: Geronimo Security plans (from ApacheCon)
Posted by Paul McMahan <pa...@gmail.com>.
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.
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.
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
>>>
>>
>
Re: Geronimo Security plans (from ApacheCon)
Posted by David Jencks <da...@yahoo.com>.
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
>>
>