I have a java client connecting to a WCF service. This service is configured to run on the host as a separate domain user (i.e. not as Local Service or Network Service). The Service publishes a userPrincipalName in its WSDL.
During the SpNego token exchange I get the following exception in the client
Defective token detected (Mechanism level: AP_REP token id does not match!)
This is the call stack:
at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:450)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:230)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:162)
If I configure the WCF service to run under Local System account the SpNego token exchange works.
Do I need to modify the code for services not running under Local system account?
Update-1
After some debugging by getting a C# client to connect with the WCF service, I found that the C# client is using a modified version of SpNego protocol called MS-SPNG. Does Java 6 support this? When I inspect the token I get an error about unsupported mechanism 1.2.840.113554.1.2.2.3.
These links explains whats happening. MS has a extension for SpNego protocol, which kicks in when we run a WCF service as a user (i.e. not as Local Service etc).
This is the MS specification for the new protocol, and here is the openjdk doc that xplains the workarounds.
Related
I tried connecting to Google cloud IOT MQTT Brocker. I am getting Not authorized to connect (5) as Exception in Java client.
The device_id and other details are correct.The public key set for the device in the cloud iot.
using the example code for the below repo.
https://github.com/GoogleCloudPlatform/java-docs-samples/tree/master/iot/api-client/mqtt_example
Another point to look at is the configured GCP IoT Core cloud region.
Had similar problem with this. I configured GCP IoT Core cloud region as "asia-east1" while on the client application side, its default cloud region is "us-central1".
If the cloud region is not configured correctly, the python/NodeJS IoT Core examples (mqtt, http, end2end) would return errors such as
Creating JWT using RS256 from private key file rsa_private.pem
Publishing message 1/100: 'test/test_1-payload-1'
('on_connect', 'Connection Refused: not authorised.')
('on_disconnect', '5: The connection was refused.')
To solve this, just pass the correct cloud region parameter to the command --cloud_region=asia-east1
Example:
python cloudiot_mqtt_example.py --project_id=project_id --registry_id=registry_id --device_id=device_id --private_key_file=rsa_private.pem --algorithm=RS256 --cloud_region=asia-east1
Couple things to check:
1) Are you sure the format of the SSL key matches what you registered? RS256 vs. RS256 with X509, etc?
2) Did you setup the TLS on the mqtt client and grab the Google root certificate?
2a) >=TLS 1.2?
3) Verify the JWT has the correct 'aud' value (project-id, not project-name), and that it's got a proper issue and expiry time?
I developing a web application with kerberos (v1.0.1) authentication.
My aim is to provide a login through the windows authentication Active Directory (Windows Server 2008 R2).
The problem is that the browser send to the Back End NTLM ticket instead of Kerberos ticket.
I used wireshak to check the communication work flow:
I make a rest call on the back end
application server response to me 401
browser call the kerberos service on the active directory and received the TGS_REP
now I expected that browser calls my rest service with the Kerberos token, but I received the NTLM token instead
My back end service, developed in JAVA, throw the following exception:
GSSException: Defective token detected
EDIT 1:
The first problem is that we used the IP to generate the SPN and the KEYTAB. So, we created the keytab in this way:
ktpass /out c:\keytab\myuser.keytab /mapuser myuser#company.com /princ HTTP/myuser.company.com#WELLD.CH /pass mypassword /ptype KRB5_NT_PRINCIPAL /crypto All
Then we added our BE server on the DNS
<ip_server> myuser.company.com
At the moment we can login with kerberos, and the BE (spring boot) successfully validate the kerberos' token, but we can't download the user information with KerberosLdapContextSource, so we adopt a workaround and used the DefaultSpringSecurityContextSource Bean.
Someone have any idea or references to rely on?
Thanks
I am working with docusign demo account and successfully getting callbacks on http (port 80) from connect listener. I have now purchased and installed the SSL certificates on server and able to access the callback link from inside and outside the network. When I changes the http:// link on connect service configuration to https://, it gives me the following error:
https://esign/api/event/envelop-event-occured ::
Error - The request was aborted: Could not create SSL/TLS secure
channel.
Anybody who can help me with this will be highly appreciated!
Callbacks from DocuSign must be using https with TLS 1.1 or above.
Please read here for more information about that - https://developers.docusign.com/esign-rest-api/guides/mutual-tls-intro
Currently at a loss for authenticating with a Microsoft Project Server 2007 instance running on IIS with Integrated Windows Authentication enabled from a Java 1.6(u19) client running on linux, RHEL 5.5.
Note: The client works on my Windows workstation.
I initially was trying to implement a JAX-WS call and found that I could not retrieve the WSDL due to authentication errors, specifically a 401.2, followed by a 500. So I simplified it to a Java class that:
Creates an Authenticator and sets it as the default with a user name/password in AD that has permissions to the project server site
Create a java.net.URL object
Create a java.net.HttpURLConnection and invoke getInputStream
It is at this point where a failure occurs.
With HttpURLConnection debugging turned on I can see:
the initial authentication failure (401.2) returned from the server with "negotiate" and "NTLM" included in the response.
the client creating an NTLM token and sending it back to the server
the server returning with a 500 status code
On the Windows server in the logs, I can see that there is no user name included in the log file only for my requestion and only a "-" which I believe means "anonymous".
My thought is that Project Server isn't liking the NTLM token that is being passed and choking. Based on the many postings on this, NTLM (v1 & v2) are suppose to be supported within Java 1.6.
Any help would be greatly appreciated...
UPDATE 6/20/12: narrowed the issue down to a local security policy setting for Network security: Minimum session security for NTLM SSP based (including RPC) servers. The setting that causes the Java client to fail is Require NTLMv2 security. The goes against what is claimed for NTLM support with the 1.6 JDK..
Some references:
Java HTTP Authentication
Blog showing Java Authenticator Impl
A while back when i had this problem, i ended up using a scheme created by somebody else.
http://devsac.blogspot.com/2010/10/supoprt-for-ntlmv2-with-apache.html
Worked for me when i had to get image files from and iis server with ntlm.
Snippet using the code above..
AuthPolicy.registerAuthScheme(AuthPolicy.NTLM, org.xyz.JCIFS_NTLMScheme.class);
HttpClient client = new HttpClient();
client.getState().setCredentials(AuthScope.ANY, new NTCredentials(userName, password, "", strDomain));
GetMethod get = new GetMethod(strImageFile);
get.setDoAuthentication(true);
client.executeMethod(get);
In Glassfish v2 I secure my JNDI lookups by enabling the "IIOP Client Authentication" checkbox in the admin console under the ORB node.
In my standalone client I then perform a "ProgrammaticLogin", which then allows me to do JNDI lookups.
In Glassfish v3 however, I get this error if want to do any JNDI lookups in the same setup:
18.08.2010 14:31:10 com.sun.enterprise.transaction.JavaEETransactionManagerSimplified
initDelegates INFO: Using
com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate
as the delegate
org.omg.CORBA.NO_PERMISSION:
----------BEGIN server-side stack trace----------
org.omg.CORBA.NO_PERMISSION:
vmcid: 0x0
minor code: 0
completed: No
I am pretty sure the "ProgrammaticLogin" works in general, since it allows me to do remote method calls on my secured EJB's (using #RolesAllowed but if the IIOP Client Auth is turned off).
The user I login with is a simple user that I created for the "file" realm.
Any ideas, why the ProgrammticLogin fails to work in Glassfish v3 for authorizing JNDI lookups?
Or what is the correct way to authenticate with the ORB from a standalone client; for this purpose?
Did you make sure appserv-rt.jar is on your classpath? It is part of every glassfish3 installation e.g. at my installation it is located here:
/opt/glassfish3/glassfish/lib
This is very important. It contains some client java classes especially: AppclientIIOPInterceptorFactory.
These add a SecClientRequestInterceptor to the ORB which cares that the username and password is added to the GIOP request sent to the server.
It took me about two days of scanning the source code of glassfish and sniffing the corba packages on the wire with wireshark until I found this.
An example how to secure a bean and write a real Java EE client can be found here:
http://download.oracle.com/docs/cd/E19798-01/821-1841/bnbzk/index.html
Hope this helps
Manuel