While accessing a HTTPS service I am facing the below issue :
Error:
..Certification authentication failed</TITLE>
...
An attempt to authenticate with a client certificate failed.
A valid client certificate is required to make this connection.
I am using Spring RestTemplate excahnge API :
restTemplate.exchange(reqInfo.getUrl(),HttpMethod.GET,requestEntity,String.class);
I tried 2 methods to provide the trustStore but still the error persists:
1.) Passing as arguments :
java -cp -Djavax.net.ssl.trustStore="trustStore.jks"
-Djavax.net.ssl.trustStorePassword="pwd" Test
2.) Setting the property
System.setProperty("javax.net.ssl.trustStore","path to truststore");
System.setProperty("javax.net.ssl.trustStorePassword","pwd");
Also I tried with simple Java code using HTTPclient then it works fine but with SPring RestTemplate none of option is working , am i missing something here ?
Note : If I do curl of that URL I get the same error as truststore is not provided . Hence I am assuming that this issue is due to TrustStore.
Finally I was able to solve the above issue .
While building the SSL context I did not load the key store ( although I was passing it via arguments) due to which I was getting Certification authentication failed as the Key store was not available .
Below code fixed the issue : (added loadKeyMaterial )
sslcontext = SSLContexts.custom().loadTrustMaterial(trustStore, new TrustSelfSignedStrategy())
.loadKeyMaterial(keyStore, keyStorePwd).build();
Related
In Springboot application we are facing issue after authentication with AD and while doing redirection.
We have added the below redirection in application.properties file:
aad.redirectHomeUri=https://icaps-userhelpertool-dev-cloudrun-kwyk47pogq-ez.a.run.app/resetpassword
Above url is cloud run url where we have deployed our code and same url we have added in AD also . But after authentication its not redirecting and we are getting below error.
19-01-2023 10:08:07.259 ERROR c.m.a.m.ConfidentialClientApplication - [Correlation ID: b396dc37-982d-4f56-ac5d-a754f24f4f53] Execution of class com.microsoft.aad.msal4j.AcquireTokenByAuthorizationGrantSupplier failed.
com.microsoft.aad.msal4j.MsalServiceException: AADSTS500112: The reply address 'http://icaps-userhelpertool-dev-cloudrun-kwyk47pogq-ez.a.run.app/resetpassword' does not match the reply address 'https://icaps-userhelpertool-dev-cloudrun-kwyk47pogq-ez.a.run.app/resetpassword' provided when requesting Authorization code.
I tried to reproduce the same in my environment
Received the error:
AADSTS50011: The redirect URI 'http://xxx/signin-oidc' specified in the request does not match the redirect URIs configured for the application '50065a5f-d3e4-426f-a4f4-1e6fbd2ed06e'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal.
This error occurred as in my code ,the http protocol it used is http But the one registered in portal is https .
This can be set properly with HttpsRedirection middleware configuration
In spring ,this occurs when your Tomcat server is behind a proxy which redirects to http protocol.
Set the below configurations in application.properties with the proper url in registered-redirect-uri and x-forwarded-proto as mentioned here spring-boot-application-with-azure-ad-throws-reply-url-does-not-match | StackOverflow
application.properties
security.oauth2.client.pre-established-redirect-uri=https://yourappurl.net/login
security.oauth2.client.registered-redirect-uri=https://yourappurl.net/login
security.oauth2.client.use-current-uri=false
server.tomcat.remote-ip-header=x-forwarded-for
server.tomcat.protocol-header=x-forwarded-proto
server.tomcat.use-relative-redirects=true
server.use-forward-headers=true
server.tomcat.internal-proxies=.*
and Add server.forward-headers-strategy=native
Reference : spring-redirect-happening-to-http-login-instead-of-https-login | Stack Overflow
Sorry folks, this may be a newb question. I'm a little lost.
My Spring-boot environment provides me with keycloak for client authorization, it gives me these.
spring.security.oauth2.resourceserver.jwt.issuer-uri
spring.security.oauth2.client.provider.keycloak.issuer-uri
spring.security.oauth2.client.registration.keycloak.* # client-id, secret, provider, grant-type
I noticed on the ClientRegistration that .issuerUri(String uri) is not avaialbe until Spring-Security v5.4.x. I am using 5.3.5, although I could bump up. I am confused what the difference is. As I would expect, I get an error when I do .tokenUri(issuerUri). I believe they are different modes/API, but I am at a loss as to what I should set in the 5.3.5 API.
Caused by: org.springframework.security.oauth2.client.ClientAuthorizationException: [invalid_token_response] An error occurred while attempting to retrieve the OAuth 2.0 Access Token Response: 405 Method Not Allowed: [{"error":"RESTEASY003650: No resource method found for POST, return 405 with Allow header"}]
So as a newb, I don't get why I have 4 choices of URI and what they do. Google and javadoc haven't been much help, so I figure I just don't know the right place to look to learn it. The only way I know how to fix this is to manual make my own HTTP call to the URI and get my Authentication token, but that would defeat the purpose of the Oauth2 library.
tokenUri represents the URI for the token endpoint. For example:
https://authz.example.org/auth/realms/myrealms/protocol/openid-connect/token
Whereas issuerUri is the URI that identifies the Authorization Server:
https://authz.example.org/auth
It's quite common for the issuer URI to be the root for more specific URIs like the token URI.
Regarding your specific error, I'd imagine that Keycloak is stating that you cannot POST to https://authz.example.org/auth, which is true. You should be POSTing to the token endpoint.
The issuer-uri Spring Boot property should cause Spring Security to look up the other endpoints and add them to a default ClientRegistration. Because of that, I'm not sure why you are also trying to programmatically configure ClientRegistration. That said, if you do need to programmatically create a ClientRegistration, you can use the issuer URI like so, and Spring Security will do the rest:
#Bean
ClientRegistrationRepository registrations() {
ClientRegistration registration = ClientRegistrations
.forIssuerLocation("https://authz.example.org/auth")
.build();
return new InMemoryClientRegistrationRepository(registration);
}
Working with CXF STS- STS client example I followed the example at https://web-gmazza.rhcloud.com/blog/entry/cxf-sts-tutorial and my sample code is at https://github.com/sampleref/CXFSecurity for reference. On debugging I found error as below at STS provider
<<||2014-07-13 18:26:50,286||http-apr-8080-exec-3|DEBUG|org.apache.ws.security.processor.UsernameTokenProcessor:50||||>> Found UsernameToken list element
<<||2014-07-13 18:26:50,287||http-apr-8080-exec-3|DEBUG|org.apache.ws.security.validate.UsernameTokenValidator:78||||>> UsernameToken user alice
<<||2014-07-13 18:26:50,287||http-apr-8080-exec-3|DEBUG|org.apache.ws.security.validate.UsernameTokenValidator:79||||>> UsernameToken password type http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
<<||2014-07-13 18:26:50,287||http-apr-8080-exec-3|DEBUG|org.apache.ws.security.processor.SignatureProcessor:115||||>> Found signature element
<<||2014-07-13 18:26:50,288||http-apr-8080-exec-3|DEBUG|org.apache.ws.security.processor.SignatureProcessor:380||||>> Verify XML Signature
<<||2014-07-13 18:26:50,292||http-apr-8080-exec-3|DEBUG|org.apache.ws.security.processor.SignatureProcessor:428||||>> XML Signature verification has failed
<<||2014-07-13 18:26:50,292||http-apr-8080-exec-3|DEBUG|org.apache.ws.security.processor.SignatureProcessor:431||||>> Signature Validation check: false
Please provide some inputs, Its really important working for me with this. I posted more detailed error from STS Client at
CXF STS client throws Request does not contain Security header/Response message does not contain WS-Addressing properties
The problem is that you are not supplying the password for the private key in the STS. So for example, adding the following to the StsPasswordCallbackHandler makes the decryption work:
x509Passwords.put("stskeyalias", "stskeypassword");
You also need to remove the BouncyCastle dependency from the STS pom.
Colm.
I think the issues, https://issues.apache.org/jira/browse/CXF-5679 and https://issues.apache.org/jira/browse/CXF-5724 were creating problems. I used CXF version 3.0.0 and able to get SAML assertion now
Thanks
I am using jmeter jms point to point queue for load testing.
But I am getting the following error:
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed]
I am using jmeter 2.11 version
I add user name and password in jndi properties. But still it is not working. Here is the configuration i am using:
QueueConnectionFactory: RemoteConnectionFactory
initial context factory: org.jboss.naming.remote.client.InitialContextFactory
url : remote://localhost:4447
JNDI Prpperties:
username: ..............
password: ...........
Your Jndi properties seem wrong, check this:
http://docs.oracle.com/cd/E19182-01/820-7853/ghyco/index.html
Login / password props are :
java.naming.security.principal
The identity of the principal for authenticating the caller to the service. For more information, see the Java API documentation for javax.naming.Context.SECURITY_PRINCIPAL.
java.naming.security.credentials
The credentials of the principal for authenticating the caller to the service. For more information, see the Java API documentation for javax.naming.Context.SECURITY_CREDENTIALS.
I have encountered similar problem while using jmeter for solace, hope this help to someone having similar issue.
For solace jms testing need to use jndi properties since there is no place holder for VPN name. JNDI properties file will look something like this:
java.naming.factory.initial=com.solacesystems.jndi.SolJNDIInitialContextFactory
java.naming.provider.url=<IP:port><br>
Solace_JMS_VPN=<VPN Name><br>
java.naming.security.principal=<username><br>
java.naming.security.credentials=<password>
Here the jndi properties has to be packaged as a jar file and placed in the jmeter lib folder in order to be picked at runtime.
jar cvf my-jndi-properties.jar jndi.properties
Hope this helps.
I need to access a JAX-WS webservice protected by SSL using Jersey Client. I have successfully got this working with limited configuration and just letting the Client use the default HTTPURLConnection API.
This approach wont work however for my overall solution because it does not allow me the flexibility to change the credentials used when making a request to the WS. I'm trying to use DefaultHTTPClient instead and then passing it to the Client object on intialization.
NTCredentials credentials = new NTCredentials("username", "password",
computerName, domainName);
DefaultHttpClient httpClienttemp = new DefaultHttpClient();
DefaultHttpClient httpClient = wrapClient(httpClienttemp);
httpClient.getCredentialsProvider().setCredentials(AuthScope.ANY, credentials );
ClientConfig config = new DefaultClientConfig();
The wrapClient method creates an X509TrustManager and overrides the necessary methods so that all certificates are accepted. It also creates a SchemeRegistry entry for https access on port 443. This configuration results in a Connection refused exception.
The strange thing is, if i add an additional entry in the SchemeRegistry for http and give it a port of 443 then the request does get sent however a Connection Reset exception then gets thrown.
The Url i use to create the WebResource object is https however the SOAPAction i declare in the header uses http. Any ideas where im going wrong?
This is a limitation of the default HTTP Client (com.sun.jersey.api.client.Client) documented in the Jersey docs. You will have to use Apache HTTP Client to achieve this functionality.
Looks like someone already recommended doing this in the answer to your previous question: Jersey Client API - authentication.
EDIT: Corrected reference to the default Jersey HTTP Client to avoid confusion.