CredentialInputUpdater in 8.0.0
by Simon Levermann
Hi,
when upgrading our existing UserStorageProvider to Keycloak 8.0.0, we
came across a possible regression: Logging in with the passwords in our
provider database still works, but changing them does not work in all cases:
In the self-service (auth/realms/{realm}/account/) interface, users can
still update their passwords and our updateCredential(...)
implementation is invoked. However, when we use the "Credentials" Tab in
the admin console to set the user's password, our updateCredential(...)
implementation is *not* invoked, and it looks like instead a new
password is created for the user, which is then *also* accepted for
logging the user in.
This seems to me like a regression and rather unexpected behaviour.
Previously, using the Credentials Tab would also invoke
updateCredential(...) instead of creating a new password.
Best regards,
Simon
4 years, 4 months
Keycoak ldap user sync
by Samy Otero
Hi all,
I am trying to sync users between keycloak and ldap (openldap). After
testing the connection I am able to pull users from ldap to keycloak and
successfully proceed with the login flow on my app.
The issue I am facing is when I am trying to create new users on keycloak
and map (create) them into the ldap server. I already mapped all the ldap
attributes I need and the user gets created but without a password. Every
time I tried to set for the very first time or update the password on
keycloak, it throws an error message.
Is there a particular way to map the password attribute from keycloak to
ldap?
Is there any other steps I need to take in order to achieve the password
creation?
Cheers
Sam
--
Samy Otero
*PSD |* Software Developer
www.psdrcs.com
*London |* 148 Fullarton St. 9th floor.
*Burlington |* 5045 South Service Rd.
4 years, 5 months
multiple accounts selector
by Michal Hlavac
hi,
We have external SAML identity provider that allows authenticate using ID card. On our side we have keycloak realm where person can have multiple accounts mapped to one ID card by attribute. So we need to allow user choose account after ID card login.
Is it possible to implement it and if yes, what is proper way to do that? Maybe custom Post Login Authentication flow?
thanks, m.
4 years, 5 months
[Authorization] User/Group based resource management
by sesnor.silva＠sapo.pt
Hello there,
I'm trying to determine the best way to manage access to resources in
a per user/group manner. I know it's possible to define an owner for a
resource but in my use-case I'd like to give a ownership to a resource
to a group of users.
This way, if any user outside of this group requested access to a
resource, any user inside the group would be able grant access
permissions to it.
What I'm currently doing is defining an attribute for each resource
called "owners" and giving it a comma separated list of IDs of the
users that own the resource. Then in the policies I control access
like this:
var permission = $evaluation.getPermission();
var identity = $evaluation.getContext().getIdentity();
var resource = permission.getResource();
var attributes = resource.getAttributes();
if (attributes['owners']) {
for(var i in attributes['owners']) {
if (attributes['owners'][i] == identity.getId()) {
$evaluation.grant();
}
}
}
It works ok... But the downside is, if in my application I want to
list all resources the user has access to, this requires me to query
every individual resource and iterate this comma separated list.
Is there an easier way? Maybe I'm missing something when it comes to UMA?
Thank you and great work on the authz module.
I hope you're not getting this email twice because I wasn't sure if I
had to register myself first into the mailist.
Best regards,
Silva
4 years, 5 months
SAML logout issues
by Manuel Waltschek
Hello dear community!
My name is Manuel Waltschek and I work for a small company located in Austria.
We are working on a project that requires SAML SSO and we decided to use keycloak for this implementation.
Use Case
1. SSO with external IdP - keycloak brokering
* SP initiated and IdP initiated login
2. SSO with Keycloak as IdP - registration and user management with keycloak server
Basic Setup
Keycloak-Server Version
4.8.3.Final
Wildfly Version
10.1.0.Final
Wildfly Adapter Version
keycloak-saml-wildfly-adapter-dist-4.8.3.Final
We also use nginx as a proxy in front of our standalone wildfly servers.
nginx config related to keycloak:
location ^~ /auth/ {
proxy_pass http://localhost:8180/auth/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
}
Deployment architecture
We deploy an ear which contains common jars and deployment-descriptors like jboss-deployment-structure.xml.
This ear also contains a war file which contains a jboss-web.xml and the keycloak-saml.xml for the client configuration.
It also contains multiple jars like auth.login.saml.web.jar in the following example.
The war itself has a web.xml and the jars in the lib folder have web-fragment.xml files.
app.ear
├── META-INF
│ ├── application.xml
│ ├── jboss-app.xml
│ ├── jboss-classloading.xml
│ ├── jboss-deployment-structure.xml
│ ├── MANIFEST.MF
└── mywar.war
├── META-INF
│ ├── MANIFEST.MF
└── WEB-INF
├── classes
├── jboss-web.xml
├── keycloak-saml.xml
├── lib
│ └── auth.login.saml.web.jar
│ ├── at
│ │ └── prismasolutions
│ │ └── ppcf
│ │ └── core
│ │ └── auth
│ │ ├── login
│ │ └── SAMLLoginServlet.class
│ ├── META-INF
│ │ ├── MANIFEST.MF
│ │ └── web-fragment.xml
└── web.xml
We have an underlying permission-based system, which requires to load roles and permissions from our database based on the Principals attributes.
This Principal is logged in via Jboss-Security or Keycloak Client Adapter. In SamlLoginServlet the SamlPrincipal is used to extract attributes and user it in the application.
Problem
The login process seems to work fine for both defined use cases
BUT
We do have some struggles and open issues concerning the logout process. Referring to another support request I have sent in June 2019, the logout does not work for our setup as documented:
https://lists.jboss.org/pipermail/keycloak-user/2019-June/018550.html
The documentation states:
"There are multiple ways you can logout from a web application. For Java EE servlet containers, you can call HttpServletRequest.logout(). For any other browser application, you can point the browser at any url of your web application that has a security constraint and pass in a query parameter GLO, i.e. http://myapp?GLO=true<http://myapp/?GLO=true<http://myapp/?GLO=true%3Chttp://myapp/?GLO=true>>. This will log you out if you have an SSO session with your browser."
In our application, the logout is implemented via a call to a Servlet, called GlobalLogoutServlet. It is registered in the web-fragment.xml in a jar contained in the war:
<servlet-mapping>
<servlet-name>GlobalLogoutServlet</servlet-name>
<url-pattern>/login</url-pattern>
</servlet-mapping>
To avoid confusion: There is a logout button in the client which refers to the URL /login?logout, this is why this is registered on the URL-Path /login.
The Implementation:
public class GlobalLogoutServlet extends HttpServlet {
private static final String LOGOUT_PARAM = "logout";
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
String queryString = req.getQueryString();
if (LOGOUT_PARAM.equalsIgnoreCase(queryString)) {
requestGlobalLogout(req, resp);
}
}
private void requestGlobalLogout(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
AuthFacade authBean = new CommonBeanAccessorGeneric<AuthFacade>().getFacade(AuthFacade.BEAN_NAME, AuthFacade.class);
try {
authBean.logout(req, resp);
} catch (PrismaLoginException e) {
throw new ServletException(e);
}
}
As you can see there is a call to an EJB (AuthFacade) which does application login (loading roles and permissions from our database) and in this case the logout which is implemented as follows:
@Override
protected void doLogout(HttpServletRequest request, HttpServletResponse response) throws PrismaLoginException {
//HttpSession session = request.getSession();
//session.invalidate();
try {
request.logout();
String ctp = getGlobalLogoutUrl(request);
response.sendRedirect(ctp);
}catch(Exception e) {
throw new PrismaLoginException(e);
}
}
private String getGlobalLogoutUrl(HttpServletRequest request) {
String ctp = request.getContextPath();
ctp = cutTrailingSlash(ctp);
ctp = ctp + "?GLO=true";
return ctp;
}
Referring to https://lists.jboss.org/pipermail/keycloak-user/2018-August/015164.html the call to HttpServletRequest.logout() is not a no-op (it does something with the SecurityContext?) , but it does not trigger a LogoutRequest to the IdP.
This is only done when I also call an URL with the queryParam "?GLO=true". This triggers another AuthnRequest (WHY?) so there is another login on the broker
After this, there happens one of two cases:
1. in idp initiated login setup - the response is sent to the application and there is an error page shown with something like "user already logged in" and a link to "back to application"
* also a logout request is never sent
2. in sp initiated login setup - there is a logout request and a logout response with status success follows up leading to a redirect to the master processing something like https://myapp/webcontext/saml and a 403 Forbidden
Please help me pin down these problems. I have read a lot of related posts, but I cannot get it to work.
https://lists.jboss.org/pipermail/keycloak-user/2018-August/015164.html
I also wrote a message to Red Hat and we might get a subscription in future to get more support, but they haven't answered yet.
I will provide some configuration details for the setup with the idp-initiated third party idp login:
jboss-web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain>keycloak</security-domain>
</jboss-web>
web.xml in war:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-app_3_0..."
version="3.0">
<display-name>myapp</display-name>
<context-param>
<param-name>resteasy.scan</param-name>
<param-value>true</param-value>
</context-param>
</web-app>
web-fragment.xml of the login module jar:
<web-fragment metadata-complete="true" version="3.0"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd">
<name>SAMLLoginFragment</name>
<servlet>
<servlet-name>GlobalLogoutServlet</servlet-name>
<servlet-class>at.prismasolutions.ppcf.core.auth.login.pvpsaml.GlobalLogoutServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>GlobalLogoutServlet</servlet-name>
<url-pattern>/login</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>PublicContentServlet</servlet-name>
<servlet-class>at.prismasolutions.ppcf.core.common.service.PublicContentServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>PublicContentServlet</servlet-name>
<url-pattern>/public/*</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>SAMLLoginServlet</servlet-name>
<servlet-class>at.prismasolutions.ppcf.core.auth.login.pvpsaml.SAMLLoginServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>SAMLLoginServlet</servlet-name>
<url-pattern>/saml_login</url-pattern>
</servlet-mapping>
<security-role>
<role-name>*</role-name>
</security-role>
<!-- protected -->
<security-constraint>
<web-resource-collection>
<web-resource-name>The protected resources</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<!-- unprotected -->
<security-constraint>
<web-resource-collection>
<web-resource-name>The unprotected resources</web-resource-name>
<url-pattern>/public/*</url-pattern>
<url-pattern>/saml_login</url-pattern>
</web-resource-collection>
<!-- note the missing auth-constraint -->
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>KEYCLOAK-SAML</auth-method>
</login-config>
<!-- Session Configuration -->
<session-config>
<cookie-config>
<path>/</path>
</cookie-config>
</session-config>
</web-fragment>
Client keycloak-saml.xml
<keycloak-saml-adapter>
<SP entityID="myapp"
sslPolicy="EXTERNAL">
<Keys>
<Key signing="true">
<KeyStore
file="${jboss.server.config.dir}/keystore/keystore.jks"
password="*****">
<PrivateKey
alias="mykey"
password="****" />
<Certificate
alias="mycert" />
</KeyStore>
</Key>
<Key encryption="true">
<KeyStore
file="${jboss.server.config.dir}/keystore/keystore.jks"
password="*****">
<PrivateKey
alias="mykey"
password="*****" />
</KeyStore>
</Key>
</Keys>
<PrincipalNameMapping policy="FROM_ATTRIBUTE"
attribute="USERID" />
<IDP entityID="idp" signatureAlgorithm="RSA_SHA256"
signatureCanonicalizationMethod="http://www.w3.org/2001/10/xml-exc-c14n#">
<SingleSignOnService signRequest="true"
validateResponseSignature="true" validateAssertionSignature="true"
requestBinding="POST"
bindingUrl="https://mybroker/auth/realms/MYREALM/protocol/saml" />
<SingleLogoutService signRequest="true"
signResponse="true" validateRequestSignature="true"
validateResponseSignature="true" requestBinding="POST"
responseBinding="POST"
postBindingUrl="https://mybroker/auth/realms/MYREALM/protocol/saml"
redirectBindingUrl="https://mybroker/auth/realms/MYREALM/protocol/saml" />
</IDP>
</SP>
</keycloak-saml-adapter>
Keycloak related snippets from the standalone.xml:
<extension module="org.keycloak.keycloak-saml-adapter-subsystem"/>
<security-domain name="keycloak" cache-type="default"/>
</security-domains>
<subsystem xmlns="urn:jboss:domain:keycloak-saml:1.1"/>
<server name="default-server">
<http-listener name="default" max-connections="100" socket-binding="http" max-post-size="10000000000$ redirect-socket="https" proxy-address-forwarding="true" enable-http2="true"/>
...
The imported metadata in the third party idp for idp initiated setup:
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://mybroker/auth/realms/MYREALM">
<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol http://schemas.xmlsoap.org/ws/2003/07/secext">
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<KeyDescriptor use="signing">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#<http://www.w3.org/2000/09/xmldsig>">
<dsig:KeyName>*****</dsig:KeyName>
<dsig:X509Data>
<dsig:X509Certificate>*****</dsig:X509Certificate>
</dsig:X509Data>
</dsig:KeyInfo>
</KeyDescriptor>
<KeyDescriptor use="encryption">
<dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#<http://www.w3.org/2000/09/xmldsig>">
<dsig:KeyName>*****</dsig:KeyName>
<dsig:X509Data>
<dsig:X509Certificate>*****</dsig:X509Certificate>
</dsig:X509Data>
</dsig:KeyInfo>
</KeyDescriptor>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mybroker/auth/realms/MYREALM/broker/myidp/endpoint"/<https://mybroker/auth/realms/MYREALM/broker/myidp/endpoint>>
<AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mybroker/auth/realms/MYREALM/broker/myidp/endpoint/clients/myapp"
index="1" isDefault="true" />
</SPSSODescriptor>
</EntityDescriptor>
I would be happy about any additional information concerning saml logout:
* Informations about all configurations related to logout in any parts of the system
* Informations about all Keycloak classes the logout process depends on
* Do we HAVE to specify a logout.jsp?
* Additional Keycloak settings - what do these really do?
* Idp Broker:
[cid:image001.png@01D5A45E.524321B0][cid:image002.png@01D5A45E.524321B0]
Example Single Logout Service URL: https://externalidp/profile/SAML2/Redirect/SLO<https://portal.salzburg.gv.at/stdportal-idp/portalverbund.gv.at/profile/S...>
[cid:image003.png@01D5A45E.524321B0][cid:image004.png@01D5A45E.524321B0]
* Client:
[cid:image005.png@01D5A45E.524321B0][cid:image006.png@01D5A45E.524321B0]
* Could these client settings have anything to do with the logout process?
[cid:image007.png@01D5A45E.524321B0][cid:image008.png@01D5A45E.524321B0]
I will be really grateful for any help resolving this issue. Please feel free to ask for more information, I will provide anything I can.
Thankfully,
Manuel Waltschek
[Logo]
Manuel Waltschek BSc.
+43 660 86655 47<tel:+436608665547>
manuel.waltschek(a)prisma-solutions.at<mailto:manuel.waltschek@prisma-solutions.at>
https://www.prisma-solutions.com
PRISMA solutions EDV-Dienstleistungen GmbH
Klostergasse 18, 2340 Mödling, Austria
Firmenbuch: FN 239449 g, Landesgericht Wiener Neustadt
4 years, 5 months
warn in keycloak cluster
by pavel.kokush
Hello
I run keycloak cluster with Standalone Clustered Configuration. There is
warn in log "The node-identifier attribute on the /subsystem=transactions
is set to the default value. This is a danger for environments running
multiple servers. Please make sure the attribute value is unique."
Should I worry about it? Is it about distributed transactions and keycloak
does not use it?
4 years, 5 months
getting keycloak token with curl from PC
by John Norris
Hello,
I have keycloak running on a linux server along with a web application.
Using a browser from a PC, I get redirected to the keycloak login page where I can authorise a user and so get access to protected resource.
I can also use curl on the command line on the server to get back and display the token.
But what I can not do is use curl on the PC (or Postman which I used initially) to get the token. I run the same curl command (except for using double quotes for the body on the PC) but on the PC I get
curl -s -X POST -H 'Content-Type: application/x-www-form-urlencoded' -d "username=user1&grant_type=password&client_id=bikes-app&password=123456" http://mint191:8080/auth/realms/master/protocol/openid-connect/token
{"error":"unauthorized_client","error_description":"INVALID_CREDENTIALS: Invalid client credentials"}
So why would a locally run curl work but a remotely run curl fail when the browser works?
Regards,
John
4 years, 5 months
Null Pointer
by Aaron Echols
Hello All,
I'm on Keycloak 5.0.0 and am getting the following error whenever I attempt
to manage the sessions. My servers have been working without issue since we
upgraded to 5.0.0 in March. I've held the same version of Java as well,
that hasn't changed either.
I'm not in a place to upgrade currently, until after the new year.
Any suggestions? Thank you :)
2019-11-22 16:27:01,451 ERROR
[org.keycloak.services.error.KeycloakErrorHandler] (default task-8)
Uncaught server error: java.lang.NullPointerException
at
org.keycloak.services.resources.admin.RealmAdminResource.getClientSessionStats(RealmAdminResource.java:614)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at
org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
at
org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
at
org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:137)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:106)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:132)
at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
at
org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
at
org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
at
org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
at
org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90)
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at
org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at
org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at
org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at
org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at
org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:745)
--
Aaron Echols
4 years, 5 months
Help needed
by Vishal Komma Reddy
Hi,
Do we have a solution for this issue yet? If so can you let us know what exactly needs to be done because we have all the certs in the key store and also the trusted certs in the trust store and the SPI we are adding in the standalone.xml :
<spi name="truststore">
<provider name="file" enabled="true">
<properties>
<property name="file" value="/opt/jboss/keycloak/standalone/configuration/xxx.keystore" />
<property name="password" value="xxx" />
<property name="hostname-verification-policy" value="WILDCARD"/>
<property name="disabled" value="false"/>
</properties>
</provider>
</spi>
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:750)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:443)
at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:416)
at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
... 88 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
at sun.security.validator.Validator.validate(Validator.java:262)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:237)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
... 101 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
Vishal
This communication and any attachment thereto may contain confidential and proprietary material of Validus Group or others, the unauthorized disclosure of which to third parties may cause permanent and irremediable damage. If you believe you received this communication in error, please contact the sender and delete it from any computer and other electronic devices on which it may have been stored. Thank you.
4 years, 5 months
