Add authClass configuration option to jolokia-osgi #225
Conversation
jolokia-jvm has the option to specify an authClass. When specified, authMode is ignored and authentication responsibility is delegated to authClass. This change enables the use of any authClass which extends org.jolokia.osgi.security.Authenticator. Signed-off-by: Ryan Goulding <ryandgoulding@gmail.com>
|
@rhuss Please let me know your thoughts on this change. Glad to make any modifications you suggest. I am trying to integrate this with OpenDaylight (osgi/karaf based); we have an existing AAA subsystem and I am trying to delegate jolokia authN responsibility to that. I am the Project Technical Leader of AAA in ODL, so let me know if you think there is a better way to do this and I can adapt internally. |
|
Thanks a lot for the PR. In fact an extension point for an restrictor makes much sense. Jolokia 2.0 already has this, but it's still in early development stage. Since I'm currently on vacations I will take care about this PR after this (2 weeks). Hope this is OK. |
|
Thanks @rhuss and enjoy your vacation! |
Project: controller fbc126f0ee9f2a50cd6450378976d4ed32c2dce8 Bug 3231 jolokia access should be controlled by aaa Due to unfortunate lack of support, we are going to have to just use basic authentication from config file for now. I have committed this patch to upstream jolokia: jolokia/jolokia#225 which will unlock power for us to use AAA. However, this won't be available until a new release is cut on Jolokia's end. The only options for jolokia-osgi bundle for authentication are basic file authn (which is implemented in this proposed changeset) and JAAS. ODL's JAAS is unencrypted and generally disregarded, so basic file authN was chosen. By default, the credentials are admin/admin. Change-Id: I35770bcf13b3cb32e59685e9bbf0ef47d73d132f Signed-off-by: Ryan Goulding <ryandgoulding@gmail.com>
Due to unfortunate lack of support, we are going to have to just use basic authentication from config file for now. I have committed this patch to upstream jolokia: jolokia/jolokia#225 which will unlock power for us to use AAA. However, this won't be available until a new release is cut on Jolokia's end. The only options for jolokia-osgi bundle for authentication are basic file authn (which is implemented in this proposed changeset) and JAAS. ODL's JAAS is unencrypted and generally disregarded, so basic file authN was chosen. By default, the credentials are admin/admin. Change-Id: I35770bcf13b3cb32e59685e9bbf0ef47d73d132f Signed-off-by: Ryan Goulding <ryandgoulding@gmail.com>
|
Sorry for the long delay. However, I'm just about to pick this up now and cut a release before the end of this week, Would an OSGi Authenticator service help you, too ? I ask because in an OSGi environment this is the canonical way to wire stuff together and we do this already for restrictors which are exposed as OSGi service. That way you could also nicely stack multiple authenticator services (much like for the restrictor). My suggestion is to use a new I think that would fit better in the current implementation (i.e. avoiding What do you think ? |
|
Seel also http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html why using |
|
Good points, rhuss. I will look into adding a service interface instead of using Class.forName(...). |
Provides the capability to enable "authMode=service" in org.jolokia.osgi.cfg. This authentication mode provides the ability to monitor the OSGi service registry for custom implementations of the Authenticator interface, resulting in delegation of authentication to third party implementations. This is particularly useful for integrating jolokia into an existing OSGi project. If "authMode=service" is enabled, authentication only succeeds if every implementation of Authenticator.authenticate(...) returns true. If no implementations are provided, then authentication fails (i.e., the system defaults to fail-closed). The initial idea was presented here: jolokia#225 Signed-off-by: Ryan Goulding <ryandgoulding@gmail.com>
Provides the capability to enable "authMode=service" in org.jolokia.osgi.cfg. This authentication mode provides the ability to monitor the OSGi service registry for custom implementations of the Authenticator interface, resulting in delegation of authentication to third party implementations. This is particularly useful for integrating jolokia into an existing OSGi project. If "authMode=service" is enabled, authentication only succeeds if every implementation of Authenticator.authenticate(...) returns true. If no implementations are provided, then authentication fails (i.e., the system defaults to fail-closed). The initial idea was presented here: jolokia#225 Signed-off-by: Ryan Goulding <ryandgoulding@gmail.com>
jolokia-jvm has the option to specify an authClass. When specified, authMode
is ignored and authentication responsibility is delegated to authClass. This
change enables the use of any authClass which extends
org.jolokia.osgi.security.Authenticator.
Signed-off-by: Ryan Goulding ryandgoulding@gmail.com