saml with an ADFS idp.
idp metadata import in sp is working fine (/FederationMetadata/2007-06/FederationMetadata.xml), i had to add idp metadata signature in spring-saml keystore but i found info in the guide for this, so no prob.
My problem is in idp refusing spring-saml metadata.
Idp administrator send me the exception:
Add-ADFSRelyingPartyTrust : ID6018: Digest verification failed for reference
CategoryInfo : InvalidData: (:) [Add-ADFSRelyingPartyTrust], CryptographicException
FullyQualifiedErrorId : ID6018: Digest verification failed for reference ...
FullyQualifiedErrorId : PS0132,Microsoft.IdentityServer.PowerShell.Commands.SetRelyingPartyTrustCommand
Set-ADFSRelyingPartyTrust : PS0132: No RelyingPartyTrust found with name ...
What do you think, SP certificate is self signed, and a sp metadata has signature in it.?
Do i have to remove the signature in the metadata or should the idp admin do something to avoid this error ?
thanks in advance
alessandro
You should try two things:
make sure your endpoints in SP metadata are using https endpoints
regenerate SP metadata without signature, or remove the signature manually
Related
I am facing an issue while connecting to one login. please help me
2022-11-22 08:49:10,491 ERROR [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (default task-509) Failed to make identity provider oauth callback: javax.net.ssl.SSLException: Connection reset:144)
I have met such an issue before. It looks like you need to trust the certificate authority of the Identity provider by adding its certificate bundle to your trust store
I'm running a Keycloak instance in standalone mode. I have configure the Keycloak as an OIDC federated IdP in the WSO2 IS and configured the WSO2 IS as a client in the Keycloak. I also have an application running which is connected to WSO2 IS and uses Keycloak for federated authentication.
I can log into the application without any issues, but when I try to logout from the application, logout happens in the Keycloak but there's the following error in the Keycloak console,
[org.keycloak.services] (default task-17) KC-SERVICES0057: Logout for client 'WSO2-IS' failed: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I tried creating a keystore, standalone/configuration/application.keystore and importing the certificate of the WSO2 IS to it and importing the certificate of the Keycloak to WSO2 IS keystore. But it didn't work. (Note that application.keystore wasn't in the standalone/configuration/ location even after the sever was started.)
I also followed this guide to setup a keystore but nothing seems to work.
Is there something I'm missing in this setup ?
Fixed the issue after checking the certs in the truststore of the Keycloak.
Reason: cert of the WSO2 IS was not properly imported and truststore was not properly configured.
I need some tips in order to understand how to perform a client authentication with x509 certificate against Keycloak.
We have a simple Spring Boot Web App (API REST) into a Kubernetes cluster.
This Web App is public exsposed through an API Gateway (Ambassador) and currently protected with a browser redirection to the Keycloak login page where user can input his username and password.
However this is not what we want.
What is necessary for us is a client authentication (React Native Mobile App) where:
Mobile App try to call our Server API REST endpoints
Ambassador check for a valid access token and (if not) respond with a 403 http status (no browser redirection)
Mobile App then redirect to Keycloak in order to perform the authentication
Keycloak doesn't show username/password login page but, instead, Mobile App pass a x509 user certificate through its Browser.
Unfortunately I can't understand how to generate a valid and trusted x509 certificate with user data (info, roles ecc.) in order to get an access token from the IdP.
And ... how can IdP check and validate this client certificate? Is it necessary a Server certificate counterpart somewhere installed on Keycloak?
What's the correct form (ex with CURL) to pass the client certificate to keycloak?
Is it neccessary to pass also the private key and why?
Please check the section X.509 Client Certificate User Authentication in section 6 of Keycloak Server Administration Guide, which describes:
how to enable and configure client certificate authentication in Wildfly and Keycloak
how to map certificate fields to user attributes
the client certificate authentication workflow with Keycloak/Wildfly (Keycloak container).
Unfortunately I can't understand how to generate a valid and trusted x509 certificate with user data (info, roles ecc.) in order to get an access token from the IdP.
Have a look a this article to generate a certificate How to create a self-signed certificate with OpenSSL
How can IdP check and validate this client certificate?
Keycloak documentation is a good starting point, check "Adding X.509 Client Certificate Authentication to a Browser Flow" and "Adding X.509 Client Certificate Authentication to a Direct Grant Flow"
if you need the whole DN for user key, you can use this RegEx on the config X509 :
set "A regular expression to extract user identity" : (.*)
add a user attribute called "usercertificate" for example and copy DN in it.
Is it necessary a Server certificate counterpart somewhere installed on Keycloak?
Not all the certificate, you can add only the DN in a user user attribute called "usercertificate".
What's the correct form (ex with CURL) to pass the client certificate to keycloak?
URL : https://localhost:9445/auth/realms//protocol/openid-connect/token
Example of code to open Keycloak TLS session :
public String openSession(
File p12File,
String passphrase,
String clientId)
throws IOException, GeneralSecurityException {
try (FileInputStream fis = new FileInputStream(p12File);) {
KeyStore keyStore = KeyStore.getInstance("PKCS12");
keyStore.load(new FileInputStream(p12File), passphrase.toCharArray());
HttpClient httpClient = HttpClients
.custom()
.setSSLContext(new SSLContextBuilder()
.loadTrustMaterial(null, TrustAllStrategy.INSTANCE)
.loadKeyMaterial(keyStore, passphrase.toCharArray())
.build())
.setSSLHostnameVerifier(NoopHostnameVerifier.INSTANCE)
.build();
HttpPost httpPost = new HttpPost(tokenEndpoint);
httpPost.addHeader("Content-Type", "application/x-www-form-urlencoded");
String data = "grant_type=password" + "&client_id="+ clientId;
StringEntity input = new StringEntity(data);
httpPost.setEntity(input);
HttpResponse response = httpClient.execute(httpPost);
return IOUtils.toString(response.getEntity().getContent(), "UTF-8");
}
}
Is it neccessary to pass also the private key and why?
no
I have an ASP.NET Core 3.0, Angular, IdentityServer4 application deployed to IIS. Which is using a server certificate exported to .pfx for token signing. (This same certificate is used for the SSL certificate but from the certificate store).
The application loads fine both as https://www.example.com and htts://example.com (no SSL errors).
However when browsing on https://www.example.com and trying to access data on any endpoints requiring authorisation, it doesn't work. The following error is observed in the response header:
www-authenticate: Bearer error="invalid_token", error_description="The issuer 'https://www.example.com' is invalid"
I'm not sure where to start looking... will this be an IdentityServer4 configuration issue?
FYI, this project was developed from the template project created by dotnet new angular -o <output_directory_name> -au Individual.
The token issuer (which is the origin of the site that issued the token) is a part of the contract between an OIDC provider and the clients and APIs that rely on it.
identityserver4 by default will use the incoming request details to determine what the value of iss should be in any tokens it issues.
As such you should usually only use a single host name for your OIDC provider - e.g. identity.example.com or something along those lines.
Another option may be to force it to use a pre-defined host name rather than determining it based on the request.
We are testing our own OIDC-IDP with a commercial client. (We don't have access to the clients code.) After some tests, the client always returns
OpenID Connect token validation failed: Token signature invalid (ID_TOKEN)
The IDP is in the wild of the web, the client is in our own network with a SSL breaker in between. We have a test client, also in the WWW, which works fine.
My question is, which certificate does the OIDC-client use to verify the signature. Is it the certificate of the website of the IDP? If so could it be that the reason for this error, is the ssl-breaker replacing the original certificate?
Note about OIDC lingo
OpenId Provider (OP) is analogous to SAML2 IdP
Relying Party (RP) is analogous to SAML2 SP
I knew what you were referring to when you wrote "IdP" and "client", but I want to mention that you'll commonly see OP and RP used for OIDC documentation / discussions.
Context and suggestions
The commercial RP you're testing with states that signature verification of the ID Token (i.e. JWT) is failing. To specifically answer your question, no, it is not using the x509 cert from the OP website to verify the signature. The key the RP uses to verify signature will depend on whether you've configured your OP to sign ID Tokens using:
HS256 (symmetric key algorithm); or
RS256 (asymmetric key algorithm)
Please have a look at the accepted answer on this thread for context:
RS256 vs HS256: What's the difference?
In the former case (HS256), your OP signs the ID Token with a secret key. And your RP must verify the signature using that same secret key. (NB: as you probably know, it's important to keep this shared secret key safe and secure.) If this is your environment, perhaps the commercial RP has a configuration option that allows you to upload or copy/paste in the secret key.
In the latter case (RS256), your OP signs the ID Token with a private key, but your RP verifies the signature using its public key counterpart. If this is your environment, perhaps the commercial RP has a configuration option to specify "jwks_uri" and "kid". These refer to the URI that your public key is published to, and its key ID, respectively.