to me it was just a reminder: "all things touching on JAAS should use clearly defined TCCL / classloader pattern or provider contract or etc."
-------- Original Message -------- Subject: Re: Securing shell commands From: Guillaume Nodet <[email protected]> To: Andrei Pozolotin <[email protected]> Cc: [email protected] Date: Tue 30 Oct 2012 12:41:13 PM CDT > How does that relate to authorization ? > > On Tue, Oct 30, 2012 at 6:17 PM, Andrei Pozolotin > <[email protected] <mailto:[email protected]>> wrote: > > few more concerns/ideas > > https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi > > > -------- Original Message -------- > Subject: Securing shell commands > From: Guillaume Nodet <[email protected]> <mailto:[email protected]> > To: [email protected] <mailto:[email protected]> > Date: Tue 30 Oct 2012 06:20:25 AM CDT >> I've worked last week on a solution for KARAF-979, i.e. providing a way >> to >> secure shell commands. >> What I came up with is the following. >> >> A new simple authentication service, exposed as an OSGi service with the >> following interface >> >> public interface AuthorizationService { >> >> void checkPermission(Subject subject, String permission); >> >> boolean isPermitted(Subject subject, String permission); >> >> } >> >> >> This service would be used transparently by karaf commands by modifying >> the >> BlueprintCommand class and calling checkPermission with the current >> Subject >> and a permission which is >> "command:" + [scope] + ":" + [command] >> >> Permissions can be set through ConfigAdmin using a single property which >> contains an xml which looks like: >> <entries> >> <entry permission="[xxx]" roles="[xxx]" type="add|set|modify" /> >> [ more entries ] >> </entries> >> >> The matching is done by checking the permission given in the call to the >> AuthorizationService with the entries in the configuration. Matching >> entries are used to compute the list of authorized roles and those roles >> are checked against the roles of the authenticated Subject. >> This mechanism is the same we had in ServiceMix 3.x. >> >> This allows to define permissions for a subshell or a single command. It >> does not provide a very easy way to split read operations from write >> operations and this would have to be done in an example configuration >> maybe >> to ease the user task. >> That said, the mechanism is easily extensible and we can later add >> permissions for JMX access or any other part of Karaf that would benefit >> from that. >> >> Thoughts welcomed, as usual. >> >> >> > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > FuseSource, Integration everywhere > http://fusesource.com
