Develop Reference

LDAP bind authentication with Jetty

I am trying to secure Confluent Control Center 7.2.2 with the jetty LdapLoginModule. I have the following jaas configuration working.
c3 {
org.eclipse.jetty.jaas.spi.LdapLoginModule required
useLdaps="true"
contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
hostname="ldaps.xxxx.xxxxx"
port="xxx"
bindDn=<user principal name>
bindPassword=<user password>
authenticationMethod="simple"
forceBindingLogin="true"
userBaseDn="DC=xxxx,DC=xxxx,DC=xxx,DC=xx"
userRdnAttribute="userPrincipalName"
userIdAttribute="userPrincipalName"
userObjectClass="user"
roleBaseDn="OU=xxxxxx,OU=xxx,OU=xxxxx,DC=xxxx,DC=xxxx,DC=xxx,DC=xx"
roleNameAttribute="cn"
roleMemberAttribute="member"
roleObjectClass="group";
};
I would like to avoid passing a bindDn and bindPassword and use the authenticating user credentials to bind instead. My understanding is that forceBindingLogin set to true should make that possible.
forceBindingLogin
Indicate whether to bind as the user that is authenticating (true), otherwise bind as the manager and perform a search to verify user password (false).
Although when I remove bindDn and bindPassword from my config I get the following error:
DAP: error code 1 - 000004DC: LdapErr: DSID-0C090A71, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v3839
It looks like bindDn is still used when forceBindingLogin is set to true.
I noticed that in the Confluence documentation, the bindDn config went from optional to required between 6.1.9 and 6.2.0. Jetty was upgraded to 9.4.39, but there is no mention as to why bindDn would now be required.

I don't have experience with Confluent Control Center, but have been dealing with a lot of Java applications and OAuth that uses LDAP authentication during the years. As a DevOps I had to also manage a few LDAP instances myself so I will be rather speaking from that background.
The authentication process with OpenLDAP requires one of the following to be true:
Allows anonymous (connection) binding
This configuration allows you to connect to the LDAP server as an anonymous user and lookup any object in the tree and therefore find any groups, users, etc.
Manager/User dn (connection) binding
This configuration mandates you to connect to the LDAP server as a pre-configured user that has access to lookup objects in the tree and find the requested groups,users,etc. You can have many Manager DNs configured to access different parts of the LDAP tree.
Notice I mentioned CONNECTION binding - think of this as how you would connect to Postgres or MySQL. You need to have some credentials in order to lookup tables or if anonymous is enabled you can do pretty much anything.
The same thing applies to LDAP servers -- anonymous binding will allow you to establish a connection and lookup anything and manager / user dn requires authentication before the connection can be established.
People are not always deeply aware of LDAP's architecture and the documentation doesn't really help there. As such, the terminology makes you jump to the rational conclusion you jumped to:
#alex: I would like to avoid passing a bindDn and bindPassword and use the authenticating user credentials to bind instead
This would work only when the LDAP server is configured to allow Anonymous connections. If it is configured to require Manager/User DN connection:
When you bind as the user the authentication will likely pass (unless LDAP is configured not to allow that at all).
Once it succeeds it you would attempt to lookup the authorization objects (roles / groups / etc). At this point it will fail due to the inability to do the needed lookups and finally the result will be failed login.
To validate if this is the case you are ending in you should:
Use some tool to the LDAP server (you can try Apache Directory Studio
Setup a connection with binds as the bespoken user (i.e. my-username; not the manager dn, not a read-only dn)
Once you are connected try to lookup the userBaseDn and roleBaseDn DN's -- you are most likely not going to see any of the roles.
If the above is true then what you want is not possible with the current LDAP server setup.
If not -- then the LDAP server truly allows you to bind as the user and to lookup the directory tree. In this case you should open up a bug report with Confluent.

Soap Connection timed out in Java client but not in SOAPUI

I created a soap client with wsimport and a given wsdl. I also used SoapUI to test the service. Using SoapUI I had no problem but when using my Java client I get
java.net.ConnectException: Connection timed out: connect
The default values I have in the requestContext are as follows
com.sun.xml.internal.ws.connect.timeout=100000
javax.xml.ws.service.endpoint.address=[fully qualified domain name endpoint]
com.sun.xml.internal.ws.request.timeout=100000
javax.xml.ws.soap.http.soapaction.use=null
com.sun.xml.internal.ws.client.ContentNegotiation=none
javax.xml.ws.soap.http.soapaction.uri=null
I've tried increasing the timeout but it still doesn't connect.
Has anyone else had a similar problem?

As you mentioned the problem is of proxy, it has been answered in below links.
How to use an HTTP proxy in java
Proxy settings in a java program
If you are using proxy with authentication then you have set authenticator along with the proxy. This is answered here.
Authenticated HTTP proxy with Java
EDIT:
As correctly mentioned by William Burnham, you have set to set the properties before calling them.
Morever, I recommend you to clear the property soon after getting response using System.clearProperty(key) as the property is set for complete instance of jvm till it is restarted and hence can cause problems for other outgoing connections.

The problem was I was behind a proxy. I did different tests and found that using a web browser (or SoapUI) I was able to access the resource but from the command line it wasn't working.
After much searching, it was a simple fix: either passing the property as a jvm argument or manually setting it in the code with System.setProperty("java.net.useSystemProxies", "true"). The JVM wasn't using the proxy on its own.
EDIT
As I used wsimport I have a jax-ws client. It's important that proxy settings be configured prior to instantiantion.
ANOTHER EDIT
If by chance you're having problems and you're using an application server to make the soap request through the proxy, you may have to specify java.net.useSystemProxies=true (or similar) in the server's configuration--for example catalina.properties if using tomcat.

Client connection to IBM MQ unauthorized

I'm trying to setup a Client connection to IBM MQ and test this using the samples application wmqjava.
I am able to connect in binding mode but I'm getting a 2035 unauthorised error when using client mode.
The steps I've taken to set this up are:
Create / run a queue manager
Create a listener
Create a SVRConn channel (multiple attempts)
I think I'm missing something with authorisation?
DEF CHL('TEST2.CHANNEL') CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER(' ')
I'm trying to connect to this on the same machine that the MQ server is running on.

Depending on the version of IBM MQ you are using, you could be being blocked by the default CHLAUTH rule which bans client connections which assert privileged user ids, or the default CONNAUTH rule which demands a password is provided for such a client connection.
Read Getting going without turning off MQ Security for instructions on how to turn both off, or use both correctly.
FYI: Your queue manager error log will tell you the reason you were blocked from accessing it.

You can put the user "mqm" in MCAUSER Field to bypass all the authorisation.
DEF CHL('TEST2.CHANNEL') CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER('mqm')
This will use all the authorities of mqm user (Default MQ admin user) to connect to Queue Manager.
Alternatively you can authorize the user to allow to connect, put, get messages.
setmqauth or getmqauth commands can help you.

Execute a command on kerberos using java and the ticket

I can execute a command using my kerberos ticket on the kerberos server by running
ssh hostname ls
it uses the kerberos ticket I got earlier by running kinit on the client.
I want to do the same thing through a java client. I have a client that can SSH to that machine using the privatekey or the username and password.
I want the java client to use the kerberos ticket.
How can I do that?

Well from what i understand your problem statement is:
Use kinit to generate a kerberos ticket
Use Java Client to send the ticket generated for authentication
I am also assuming you are writing the code for the java client:
Well in that case you to use a jaas.conf
Sample Jaas conf:-
com.sun.security.jgss.krb5.initiate {
com.sun.security.auth.module.Krb5LoginModule required
isInitiator=true
useTicketCache=true
doNotPrompt=true;
};
Set jaas conf via system property:-
-Djava.security.auth.login.config=jaasconffilepath
This will allow you to pick up whatever is defined in default credential cache(in your case that is populated with kinit)
Once you do this:-
LoginContext lc = new LoginContext();
lc.login()
After this use Subject.doAs to elevate privileges and get your job done:-
Subject.doAs(lc.getSubject(), new YourAction())
Here YourAction is a class you define (which must implement PrivilegedExceptionAction) and in its run method do whatever you want to.
P.S In case you are not "coding" your java client you need to check for jaas documentation of the module in question and see if it is supported or not. Then all you need to do is use your jaas.conf file and you are good to go.
P.S You can avoid kinit all together by putting useTicketCache=false and doNotPrompt=false. Then you can specify password and username in your client and it will get you ticket.
P.S Please ensure you define the system property for krb5.conf for any of this to work: -D java.security.krb5.conf=krb5conffilepath

Websphere MQ 7.5: User ID Access

I've installed the Websphere MQ 7.5 and written a Java-client to connect to the queue. To perform the task, I'ev created a custom connect-to-server channel that is based on the SYSTEM.DEF.SVRCONN channel.
Firstly, to block all users with administrator privileges and all anauthorized users for all channels I've types such a command (runmqsc TEST_MANAGER): SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST('nobody', *MQADMIN) . Now I see this restriction in the MQ Explorer (TEST_MANAGER -> Channels -> Channel Identification Records).
After that, to provide my test user (Java-client) with an access, I've typed such a command:
SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS('*') MCAUSER('TestUser') .
Lastly, I've set the username/password pair in the Spring's UserCredentialsConnectionFactoryAdapter where the username is TestUser.
The problem is I can't connect with the 2035 MQRC_NOT_AUTHORIZED exception. If I remove the 'nobody'/*MQADMIN blocking rule, everything works fine (only the rule for the TestUser client rule presents).

SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS('*')
MCAUSER('TestUser')
I do not think you understand this command. This command says that ALL applications connecting on channel 'TEST_CHANNEL' will use UserID of 'TestUser'.
I've set the username/password pair in the Spring's
UserCredentialsConnectionFactoryAdapter where the username is
TestUser.
Setting a Password is pointless, as MQ does NOT perform authentication. You need to purchase a 3rd party product (i.e. MQAUSX) to handle the authentication. Also, your CHLAUTH command is actually overriding whatever UserID you set in your Spring application.
The problem is I can't connect with the 2035 MQRC_NOT_AUTHORIZED exception. If I remove the 'nobody'/*MQADMIN blocking rule, everything works fine (only the rule for the TestUser client rule presents).
Did you use the setmqaut command to give the UserID 'TestUser' the appropriate access to the queue manager and queue?
Turn on the queue manager's Authority Event and to see exactly why MQ is returning 2035.