Camel + JMX + LDAP authentication with org.apache.camel.jmx.createRmiConnector - apache-camel

all.
Have been trying to get remoted JMX with JAAS authentication to work usin Camel version 2.10.3 + Java 6.
The app uses Java DSL and is "hand wired", and runs with system properties:
-Dcom.sun.management.jmxremote.authenticate=true
-Djmx.remote.x.login.config=StagingJmxAuthConfig
-Dorg.apache.camel.jmx.usePlatformMBeanServer=true
-Djava.security.auth.login.config=./src/main/resources/conf/ldap-auth.config
-Dcom.sun.management.jmxremote.ssl=false
-Dorg.apache.camel.jmx.createRmiConnector=true
-Dorg.apache.camel.jmx.rmiConnector.registryPort=9140
However, for all intents and purposes it seems that I might as well be running with authentication/authorization switched off.
Debugging into the JRE's JMX and JAAS classes (and Camel as well), note the following:
In the class org.apache.camel.management.DefaultManagementAgent:
cs = JMXConnectorServerFactory.newJMXConnectorServer(url, null, server);
This in turn later creates an instance of javax.management.remote.rmi.RMIJRMPServerImpl with an empty Map for the env constructor argument.
Now, I wonder if there's something that's just escaping me -- when a request later comes to the the connector, and the javax.management.remote.rmi.RMIServerImpl does a doNewClient(), it can't possibly trigger any JAAS activity?
Line 197-208 of RMIServerImpl - remember Camel sets "env" to null, which is translated to empty map:
JMXAuthenticator authenticator =
(JMXAuthenticator) env.get(JMXConnectorServer.AUTHENTICATOR);
if (authenticator == null) {
/*
* Create the JAAS-based authenticator only if authentication
* has been enabled
*/
if (env.get("jmx.remote.x.password.file") != null ||
env.get("jmx.remote.x.login.config") != null) {
authenticator = new JMXPluggableAuthenticator(env);
}
}
Am I correct in assuming that to get remoted, JAAS authenticated JMX to work one must hand code the JMX RMI connector setup?
Shouldn't Camel have provided an environment to get JAAS to work? Doesn't even seem to touch the JAAS config file...
UPDATE: SOLVED
Setting the following system properties on the VM did the trick:
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=9410
-Dcom.sun.management.jmxremote.authenticate=true
-Djmx.remote.x.login.config=StagingJmxAuthConfig
-Dorg.apache.camel.jmx.usePlatformMBeanServer=true
-Djava.security.auth.login.config=./src/main/resources/conf/ldap-auth.config
-Dcom.sun.management.jmxremote.ssl=false
-Dorg.apache.camel.jmx.createRmiConnector=false
-Dcom.sun.management.jmxremote.login.config=StagingJmxAuthConfig
For us, using a secured LDAP, the following is the login config:
StagingJmxAuthConfig {
com.sun.security.auth.module.LdapLoginModule REQUIRED
java.naming.security.authentication="simple"
java.naming.security.principal="cn=Directory Manager"
java.naming.security.credentials="PASSWORD"
userProvider="ldap://LDAPHOST:389/BASEDN"
userFilter="(&(uid={USERNAME})(appRole=SOME_VALUE))"
authzIdentity=monitorRole
debug=true
useSSL=false;
};
Now I'm able to connect using jmxterm:
java -jar jmxterm-1.0-alpha-4-uber.jar -l service:jmx:rmi:///jndi/rmi://THEHOST:9410/jmxrmi -u LDAPUSER -p LDAPPASS
Note that the JNDI RMI name is missing the "/camel" postfix -- this is the only difference, it seems.
HOORAY!

In essence:
Use Java6 authenticated JMX remoting
Set org.apache.camel.jmx.createRmiConnector=false
Set org.apache.camel.jmx.usePlatformMBeanServer=true
The example above also shows how to connect to a search protected LDAP, which is actually isolated as the application in question uses a different LDAP for JNDI lookup for JMS.

Related

Connecting to an external HTTP api behind a proxy from nifi

I have a apache/nifi:latest instance spun inside an Amazon Linux 2 EC2. For reference, see this guide: here
I have a QuerySalesforceObject ver. 1.18.0 that makes use of StandardOauth2AccessTokenProvider.
The oauth2 provider url is configured at https://test.salesforce.com/services/oauth2/token
I can curl this url from the box and from inside the docker container just fine (I don’t get a timeout).
[root#ip-10-229-18-107 \~\]# docker exec -it nifi_container_persistent /bin/sh
printenv | grep -i proxy
HTTPS_PROXY=http://proxy.MY_DOMAIN.com:3128
no_proxy=localhost,127.0.0.1,MY_DOMAIN.com,.amazonaws.com
NO_PROXY=localhost,127.0.0.1, MY_DOMAIN.com,.amazonaws.com
https_proxy=http://proxy.MY_DOMAIN.com:3128
http_proxy=http://proxy.MY_DOMAIN.com:3128
HTTP_PROXY=http://proxy.MY_DOMAIN.com:3128
curl https://test.salesforce.com/services/oauth2/token
{"error":"unsupported_grant_type","error_description":"grant type not supported"}#
But when I run the task, oauth2 fails with an error
java.io.UncheckedIOException: OAuth2 access token request failed
Caused by: java.net.SocketTimeoutException: connect timed out
This leads me to believe the proxy settings are not being honored by the class. How can I fix this?
Here’s more info on this class: https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-oauth2-provider-nar/1.17.0/org.apache.nifi.oauth2.StandardOauth2AccessTokenProvider/index.html
The standard way to interface with HTTP resources with a proxy in Nifi is via StandardProxyConfigurationService: https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-proxy-configuration-nar/1.19.1/org.apache.nifi.proxy.StandardProxyConfigurationService/index.html
If a component does not have this property, then it means it does not support it.
You can try bootstrapping proxy settings into nifi with /opt/nifi/nifi-current/conf/bootstrap.conf. But there is no standard and support of proxy is not guaranteed. Implementation (bugs and all) depends on the library. aws-java-sdk ver. 1x, for example, has a bug where nonProxyHosts is not honoured. https://github.com/aws/aws-sdk-java/issues/2797
java.arg.18=-Dhttp.nonProxyHosts="foo|localhost|*.bar.org"
java.arg.19=-Dhttp.proxyHost=proxy.foo.com
java.arg.20=-Dhttp.proxyPort=123
java.arg.21=-Dhttp.proxyUser=foo
java.arg.22=-Dhttp.proxyPassword=bar
java.arg.23=-Dhttps.nonProxyHosts="foo|localhost|*.bar.org"
java.arg.24=-Dhttps.proxyHost=proxy.foo.com
java.arg.25=-Dhttps.proxyPort=123
java.arg.26=-Dhttps.proxyUser=foo
java.arg.27=-Dhttps.proxyPassword=bar

How to setup CouchDB with JWT auth?

I'm trying to setup just for CouchDB, so I can use my current API tokens to authenticate in CouchDB.
But the docs don't seem to provide enough information to set this up.
I don't understand what the payload of the gut needs to contain identifying the user. How do I configure the jwt secret?
Is there any simple example out there or something like or tutorial to do this correctly?
this thread may be helpful:
https://github.com/apache/couchdb/discussions/2947
edit:
ok i found a configuration that worked for me - this solution won't be suitable for anything more than a testing couchdb instance.
configure local.ini (docker image)
1.1 -> ssh to your docker docker exec -it bash
1.2 -> install vim for convenience and disable visual mode:
$ apt-get update
$ apt-get install vim
$ echo "set mouse-=a" >> ~/.vimrc
1.3 -> update local.ini
$ vi /opt/couchdb/etc/local.ini
in [chttpd] section add line
authentication_handlers = {chttpd_auth, jwt_authentication_handler}, {chttpd_auth, cookie_authentication_handler}, {chttpd_auth, default_authentication_handler}
at the very end of the file add jwt_keys config
[jwt_keys]
hmac:_default = aGVsbG8=
hmac:foo = aGVsbG8y
restart your container
configure postman :
bearer token for _default hmac is
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEiLCJleHAiOjE1OTI2MTEyMDB9.Y9jNgSeSBl54V2MHg1hXhivyZsdXTeiAVJR2DSlF6LQ
put it into postman and issue following get request:
http://localhost:5984/_session
you should see something like :
{"ok":true,"userCtx":{"name":"user_1","roles":[]},"info":{"authentication_handlers":["jwt","cookie","default"],"authenticated":"jwt"}}
now go in your browser to couchdb ui and login as admin
http://127.0.0.1:5984/_utils/#login
then click the "lock" icon next to the database you wish the user_1 to have privileges and update the permissions accordingly.
check
check if your user_1 authenticating via jwt has permissions on the database by issuing appropriate request, for example
http://localhost:5984/campaigns

how to connect samba AD DC to koha ldap

I have installed koha 20.11 and samba4 AD and Kerberos .
I have tried to connect by the terminal using the below LDAP search query and its working fine,
$ ldapsearch -H ldap://MyIp -x -D "CN=Administrator,CN=Users,DC=domain,DC=in" -w "pass#123" -b "CN=Users,DC=domain,DC=in" sAMAccountName=admin
I want to connect samba AD to koha LDAP.
but I am getting the following error.
LDAP search failed to return object : 00002020: Operation unavailable without authentication at /usr/share/test_koha/lib/C4/Auth_with_ldap.pm line 98.
samba configuration :
[global]
dns forwarder = <myIp>
netbios name = DC1
realm = <DC my domain>
server role = active directory domain controller
workgroup = <DC>
idmap_ldb:use rfc2307 = yes
server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc, dnsupdate, dns, s3fs
#ldap server require strong auth = no
ldap server require strong auth = no
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[netlogon]
path = /var/lib/samba/sysvol/<DC my domain>/scripts
read only = No
koha ldap conf.:
<useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on -->
<ldapserver id="dc1">
<hostname>ldap://ldap domain</hostname>
<base>CN=Domain Computers,CN=Users,DC=koha,DC=kohaconnect,DC=in</base>
<user>CN=Administrator,CN=Users,DC=koha,DC=kohaconnect,DC=in</user>
<pass>pass#123</pass>
<replicate>1</replicate>
<update>1</update>
<auth_by_bind>1</auth_by_bind>
<update_password>1</update_password>
<principal_name>CN=%s#koha.kohaconnect.in</principal_name>
<mapping>
<userid is="sAMAccountName"></userid>
<password is=""></password>
</mapping>
</ldapserver>
NOTE : we are not using koha`s default command, i.e. koha-common and service memcached.
• You are getting this error because you have not restarted the koha-common service and the Memcached service inherent. You can do so by running the below command and checking if the configuration has correctly been done for you: -
‘ $ service koha-common restart && service memcached restart
$ export PERL5LIB=/usr/share/koha/lib/ && export KOHA_CONF=/etc/koha/sites/library/koha-conf.xml && perl /usr/share/koha/opac/cgi-bin/opac/opac-user.pl userid=user1 password=password ‘
Please ensure to adapt the path to the koha-conf.xml, as well as user and password. Also, please note that you can bind to LDAP as user at REALM or NT4DOM\username. So, try doing that.
Find the below link for reference: -
https://openschoolsolutions.org/koha-ldap-setup/

Using embedded jetty with camel-cxf

I have a couple of rest routes defined in my Camel project and now I'm trying to add a SOAP service to my project using the same jetty embedded server.
I have something like this:
restConfiguration()
.component("jetty")
.host("0.0.0.0")
.port(8080)
;
CxfEndpoint cxfEndpoint = new CxfEndpoint();
cxfEndpoint.setCamelContext(getContext());
cxfEndpoint.setServiceClass(TestService.class);
cxfEndpoint.setAddress("http://0.0.0.0:8080/test");
from(cxfEndpoint)
.log(LoggingLevel.INFO, log, "test");
When I try to run the application, I get this error message:
Web server failed to start. Port 8080 was already in use.
Look like it's trying to start 2 instances of Jetty using the same port and that's why it's failing.
I would really like to make the cxf endpoint work with the embedded Jetty used for my other services. Is there any way to do that?

Sonar 4.1.1 with LDAP 1.4 Configuration

I am trying to configure the Sonar with windows Active directory. I am getting the below error.
ERROR [rails] Error from external users provider: Unable to retrieve details for user xxx.xxx in
The below configurations are done in sonar.property file
# LDAP configuration
# General Configuration
sonar.security.realm=LDAP
ldap.authentication: simple
sonar.security.savePassword=true
sonar.authenticator.createUsers=true
ldap.url=ldap://xxxx.group.root.ad
# User Configuration
ldap.user.baseDn=OU=Users,OU=Customs,OU=Group,dc=group,dc=root,dc=ad
ldap.user.request=(&(objectClass=inetOrgPerson)(uid={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
# Group Configuration
ldap.group.baseDn=OU=Customs,OU=Group,dc=group,dc=root,dc=ad
#ldap.group.request=(&(objectClass=posixGroup)(memberUid={uid}))
ldap.group.request=((objectClass=group)(member={dn}))
anybody have an idea to fix the issue in sonar.
Regards
Arun.
I had similar issue with LDAP 2.1 on SonarQube 5.6 (LTS)
tl'dr
This format of ldap.user.request worked for me -
ldap.user.request=(uid={login})
If you are still reading ...
Here are some things that helped me resolving the issue
sonar.log :
Turn the DEBUG ON and look for the actual ldap search query thats getting build and the ldap context.
2017.03.14 00:35:04 DEBUG web[o.s.p.l.LdapSearch] Search: LdapSearch{baseDn=dc=test,dc=com, scope=subtree, request=(&(objectClass=inetOrgPerson)(uid={0})), parameters=[harvey], attributes=[mail, cn]}
2017.03.14 00:35:04 DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://ldap.test.com, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.security.principal=uid=user,ou=People,dc=test,dc=com, com.sun.jndi.ldap.connect.pool=true, java.naming.security.authentication=simple, java.naming.referral=follow}
ldapsearch :
Run lapsearch command with same parameters from the logs (step #1)
$ldapsearch -x -L -D"uid=user,ou=People,dc=test,dc=com" -w"pass" -b"ou=People,dc=test,dc=com" "(uid=harvey)" mail cn
sonar.properties -
here is my working LDAP configuration
#General Configuration
sonar.security.realm=LDAP
ldap.url=ldaps://ldap.test.com
ldap.bindDn=uid=user,ou=People,dc=test,dc=com
ldap.bindPassword=pass
#User Configuration
ldap.user.baseDn=ou=People,dc=test,dc=com
ldap.user.request=(uid={login})
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
#Group Configuration
ldap.group.baseDn=ou=Group,dc=test,dc=com
ldap.group.request=(&(objectClass=posixGroup)(memberUid={uid}))
ldap.user.request & ldap.group.request
From the step #1 you could find out whats the correct format for query filter parameter in your case and values for bindDn (-D) and baseDn _-b)
Hope this helps =)
Thanks!
I've just encountered a similar error in Sonar 5.1.1. Here's how I solved it:
The Base DN is incorrect for use with an AD server. This worked for me:
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
Anonymous authentication to an AD server apparently doesn't work with Sonar's LDAP plugin (this assumption is supported by the documentation which specifies anonymous authentication against an AD server as "untested"). You'll need to specify a Bind DN (here meaning a user) for connecting with the AD server:
ldap.bindDn=<user>#<domain>
ldap.bindPassword=secret

Resources