` <security-constraint>
<web-resource-collection>
<web-resource-name>myapp</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>admin</role-name>
</security-role>
<login-config>
<auth-method>KEYCLOAK</auth-method>
<realm-name>TESTAPP</realm-name>
</login-config>`
I am trying to secure my web application deployed on tomcat with redhat SSO.. But when I deploy my application on the Linux box and start the tomcat server, I get the below error,
02-Apr-2020 11:14:26.046 SEVERE [main] org.apache.catalina.startup.ContextConfig.authenticatorConfig Cannot configure an authenticator for method [KEYCLOAK]
02-Apr-2020 11:14:26.047 SEVERE [main] org.apache.catalina.startup.ContextConfig.configureStart Marking this application unavailable due to previous error(s)
When I go to web.xml and change the authentication method from KEYCLOAK to BASIC, I'm able to start the application but on entering the web address, instead of redirecting to the SSO page, Iget a small popup for user anme and address.Can anyone think what's going on?
Related
I have a JAX-RS application deployed in WildFly. The application's endpoints shall be protected by Keycloak with Access Type: bearer-only. This works perfectly fine for WildFly versions up to 24.
Starting from WildFly 25 the Keycloak adapter is deprecated and one should migrate to the new Elytron subsystem. According to this WildFly issue https://issues.redhat.com/browse/WFLY-15485 however the OIDC adapter is not ready yet to work with bearer-only. But it is mentioned that it should still be possible using the Keycloak Wildfly adapter.
Also the latest Keycloak documentation and this thread in Google Groups states this.
So I installed the adapter from this location and ran the installation script:
https://github.com/keycloak/keycloak/releases/download/16.1.1/keycloak-oidc-wildfly-adapter-16.1.1.zip
./bin/jboss-cli.sh --file=bin/adapter-elytron-install-offline.cli -Dserver.config=standalone-full.xml
When deploying the application I get thte following error message:
java.lang.IllegalStateException: The required mechanism 'KEYCLOAK' is not available in mechanisms [BASIC, CLIENT_CERT, DIGEST, FORM] from the HttpAuthenticationFactory
Setup
WildFly 26 (Jakarta EE 8)
Keycloak 16.1.1
web.xml
<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://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<!-- Security configuration -->
<security-constraint>
<web-resource-collection>
<web-resource-name>admin-api</web-resource-name>
<url-pattern>/administration/*</url-pattern>
<url-pattern>/operations/*</url-pattern>
<url-pattern>/applications/*</url-pattern>
<url-pattern>/entities/*</url-pattern>
</web-resource-collection>
</security-constraint>
<login-config>
<auth-method>KEYCLOAK</auth-method>
<realm-name>this is ignored currently</realm-name>
</login-config>
<security-role>
<role-name>*</role-name>
</security-role>
</web-app>
I managed to implement Bearer Token Authorization with Keycloak and Elytron in WildFly 26 in order to control access to RESTful Web services in a Web Module (.war) of an Enterprise Application (.ear), but the solution is not without problems. This is what I did:
Define an elytron token realm
/subsystem=elytron/token-realm=xyz2ap112-token-realm/:add(\
principal-claim=preferred_username,\
oauth2-introspection={\
client-id=xyz2ap112-web-api,\
client-secret=${env.keycloak_client_secret},\
introspection-url=${env.keycloak_introspection_url}\
}\
)
Define an elytron role decoder
/subsystem=elytron/simple-role-decoder=xyz2ap112-realm-access-roles/:add(\
attribute=realm_access_roles\
)
Warning: the default "Token Claim Name" for Keycloak realms is "realm_access.roles". For this role decoder to work, I had to change it to "realm_access_roles" (no dot). I'll mention this again when I talk about the problems with this solution.
Define an elytron security domain
/subsystem=elytron/security-domain=xyz2ap112-token-security-domain/:add(\
realms=[{realm="xyz2ap112-token-realm",role-decoder="xyz2ap112-realm-access-roles"}],\
default-realm=xyz2ap112-token-realm,\
permission-mapper=default-permission-mapper\
)
Define an elytron HTTP authentication factory
/subsystem=elytron/http-authentication-factory=xyz2ap112-web-api-authentication-factory/:add(\
security-domain=xyz2ap112-token-security-domain,\
mechanism-configurations=[{\
mechanism-name=BEARER_TOKEN,\
mechanism-realm-configurations=[realm-name=xyz2ap112-token-realm]\
}],\
http-server-mechanism-factory=global\
)
Define two application security domains
ejb3 subsystem
/subsystem=ejb3/application-security-domain=xyz2ap112-web-api-security-domain/:add(\
security-domain=xyz2ap112-token-security-domain\
)
Warning: the war that contains the web services does not contain the EJBs it needs; those are in a separate EJB Module (.jar). I guess that is why I had to define this application security domain in the ejb3 subsystem.
undertow subsystem
/subsystem=undertow/application-security-domain=xyz2ap112-web-api-security-domain/:add(\
http-authentication-factory=xyz2ap112-web-api-authentication-factory,\
override-deployment-config=true\
)
Configure application’s jboss-web.xml and web.xml
<jboss-web>
<context-root>/xyz2ap112-web-api</context-root>
<resource-ref>
<res-ref-name>jdbc/xyz2ap112</res-ref-name> <!-- Logical name only. -->
<jndi-name>java:/jdbc/xyz2ap112</jndi-name> <!-- Real JNDI name. -->
</resource-ref>
<security-domain>xyz2ap112-web-api-security-domain</security-domain>
</jboss-web>
The security-domain is the application security domain defined in the undertow subsystem.
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>xyz2ap112-web-api-security-domain</realm-name>
</login-config>
The real-name in login-config is the application security domain defined in the undertow subsystem.
PROBLEMS
As I said before, this solution is not without problems. Given that my Enterprise Application (.ear) also has another Web Module (.war), which contains the GUI components of the application and no Web Services, this solution works as long as the auth-method of that second Web Module is FORM or BASIC. And, as you might have already guessed, I want to use OIDC.
Using OIDC to control access to the application is very straightforward, as properly explained by Farah Juma in her article Securing WildFly Apps with OpenID Connect. But that works as long as the "Token Claim Name" of the Keycloak realm is "realm_access.roles" (its default value). With that name the simple-role-decoder doesn’t work. So, I guess a custom role-decoder is required. Given that my application is able to define and administer roles and role assignments on its own, instead of writing a custom role-decoder, I used a constant-role-mapper to get a single role that allows the web services to execute and check permissions using the roles defined within the application. Once again, that works as long as the auth-method of that second Web Module is FORM or BASIC; with OIDC, the web services are not executed; client gets an HTTP 500 (see below). There is no additional information in the logs of any of the running WildFly (Keycloak and application).
This is the oidc.json file of the GUI Web Module:
{
"client-id": "xyz2ap112-web",
"confidential-port": 8543,
"principal-attribute": "preferred_username",
"provider-url": "http://localhost:8180/auth/realms/jrcam",
"public-client": true,
"ssl-required": "external"
}
And this is the client exception:
Exception in thread "main" javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
at org.glassfish.jersey.client.JerseyInvocation.convertToException(JerseyInvocation.java:1098)
at org.glassfish.jersey.client.JerseyInvocation.translate(JerseyInvocation.java:883)
at org.glassfish.jersey.client.JerseyInvocation.lambda$invoke$1(JerseyInvocation.java:767)
at org.glassfish.jersey.internal.Errors.process(Errors.java:316)
at org.glassfish.jersey.internal.Errors.process(Errors.java:298)
at org.glassfish.jersey.internal.Errors.process(Errors.java:229)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:414)
at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:765)
at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:428)
at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:324)
at org.xyz.jax.rs.client.base.AbstractFacadeServiceClient.find(AbstractFacadeServiceClient.java:28)
at xyz2.BarrioFacadeClient.find(BarrioFacadeClient.java:40)
at xyz2.BarrioFacadeClient.main(BarrioFacadeClient.java:24)
If the auth-method of the Web Services Web module is OIDC, the response the client gets is html corresponding to the Keycloak login page.
<html xmlns="http://www.w3.org/1999/xhtml" class="login-pf">
...
<h1 id="kc-page-title">
Sign in to your account
</h1>
...
</html>
This is the oidc.json file of the Web Services Web Module:
{
"client-id": "xyz2ap112-web-api",
"confidential-port": 8543,
"principal-attribute": "preferred_username",
"provider-url": "http://localhost:8180/auth/realms/jrcam",
"ssl-required": "external",
"bearer-only": true,
"verify-token-audience": true,
"realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAk3PD30r3SQBqnO15g/Jc5z3NFnt9HLA6QlQt2QLtxvGhLcerTD2rVWCst/4NSQev9dBscFnwxXyAoZAqTm7w0oPzlhw1Xbqt1dpKdNjMtbJxmpqzCRLTjmNatPmoAGx+9TWOPKw1qfEwZOy9xOqnCbBeT5eGCAXci+wvt8mpNX9lpAguFxgpFtyVc0at35Lw3BdZ13+6Ljxu6Z+mam1tQ9mwey0ubfhV3NK0eN8jruKWrCyGw6DRbmvKFTwQa5akDbMWt3H/HaSLMXBOrBKq9He6azVL3dkbdd40drgHtI8G+ANC1NhOPzjPtuifo9U2wHD6o8S03o35mm4xjJNcqQIDAQAB",
"credentials": {
"secret": "8c98045a-4640-46e7-9f68-74a289e43b7e"
}
}
I hope this partial solution will help someone and also that someone can tell me how to implement a complete solution.
I finally got it working without the Keycloak adapter, i.e. using the new built-in Elytron subsystem.
oidc.json (located in the WEB-INF directory)
{
"realm": "myrealm",
"client-id": "my-client-app",
"auth-server-url": "${keycloak.url}/auth",
"provider-url": "${keycloak.url}/auth/realms/myrealm",
"bearer-only": true,
"enable-cors": true,
"ssl-required": "none"
}
web.xml
<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://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<!-- other configuration -->
<login-config>
<auth-method>OIDC</auth-method>
</login-config>
</web-app>
I want to remove the authentication of user for kie-server. For this I have tried to remove the below mentioned configuration from the web.xml file
<security-constraint>
<web-resource-collection>
<web-resource-name>REST web resources</web-resource-name>
<url-pattern>/services/rest/*</url-pattern>
<http-method>GET</http-method>
<http-method>PUT</http-method>
<http-method>POST</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>kie-server</role-name>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
//from above config removed this portion
<auth-constraint>
<role-name>kie-server</role-name>
<role-name>user</role-name>
</auth-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>KIE Server</realm-name>
</login-config>
Now server is starting but not able to see the task/claim/start/finish task
So where should I modify the configurations so that I can use the kie-server server without login. And want to perform operations based on groups.
You see, task service is a separate module in kie. In that sense, it is wise to make an autologin then to chase all the places that inherit authentication.
I have JBoss EAP 7
So I have done:
unzip keycloak-eap7-adapter-dist-3.2.1.Final.zip
and
./bin/jboss-cli.sh --file=adapter-install-offline.cli
and added the <security-constraint> element to web.xml:
<security-constraint>
<web-resource-collection>
<web-resource-name>Admins</web-resource-name>
<url-pattern>/admin/*</url-pattern>
...
<security-role>
<role-name>admin</role-name>
...
and in my standalone.xml, I have:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
<secure-deployment name="snack.war">
<realm>Netzportal</realm>
<resource>netzportal</resource>
<public-client>true</public-client>
<auth-server-url>http://localhost:8180/auth</auth-server-url>
<ssl-required>EXTERNAL</ssl-required>
</secure-deployment>
</subsystem>
And in the keycloak admin console I have registered the web application as client. The client opens at http://localhost:10080/czo/login.xhtml. So I have entered http://localhost:10080/czo/* as Valid Redirect URIs.
But when the application is running and I open http://localhost:10080/czo/login.xhtml, I do not get redirected to keycloak (which is also running)
You seems to be missing following entry ( since it does not appear in your listed web.xml configuration) which actually tell which kind of authentication to use for login
<login-config>
<auth-method>KEYCLOAK</auth-method>
<realm-name>Netzportal</realm-name>
</login-config>
For more details on configuration check the docs.
I had the same problem, after a lot of suffering, I found that the web.xml file in the wrong folder
After logging in using HttpServletRequest.login(String, String), using the code below, on following requests I still get a Basic Authentication prompt. Why is the login function not working in my configuration?
My endpoint:
#POST
#Path("login")
#Consumes(MediaType.APPLICATION_JSON)
public void login(#Valid LoginRequest loginRequest) {
try {
User user = userController.findUserByUsername(loginRequest.getUsername()).orElseThrow(NotFoundException::new);
httpServletRequest.login(loginRequest.getUsername(), loginRequest.getPassword());
log.info(securityContext); // not null now!
}
catch (ServletException e) {
throw new NotAuthorizedException(e.getMessage(), e, AuthenticationHeaderFilter.CHALLENGE);
}
}
And my jboss-web.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.jboss.com/xml/ns/javaee
http://www.jboss.org/j2ee/schema/jboss-web_5_1.xsd">
<security-domain>MyRealm</security-domain>
</jboss-web>
And my web.xml:
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>MyRealm</realm-name>
</login-config>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>user</role-name>
</security-role>
<security-constraint>
<display-name>Authenticated content</display-name>
<web-resource-collection>
<web-resource-name>Authentication required</web-resource-name>
<url-pattern>/api/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<display-name>Anonymous content</display-name>
<web-resource-collection>
<web-resource-name>Exclude from Security</web-resource-name>
<url-pattern>/api/me/login</url-pattern>
</web-resource-collection>
</security-constraint>
Actually, the contract for HttpServletRequest#login does not mandate that the authenticated identity be remembered for the duration of the HTTP session (if one already exists), and certainly not that an HTTP session should be created upon successful authentication (for if one does not exist).
Technically speaking, the HttpServletRequest#login call goes straight through to the identity store (the method's Javadoc uses the term login mechanism for that). An identity store is a kind of database that typically only performs the credential validation and does not have knowledge about its environment (i.e. doesn't know about HTTP sessions, or remote EJB context IDs, or JCA inflow security IDs of whatever).
The authentication mechanism IS aware of its environment, and this one is invoked by calling HttpServletRequest#authenticate. But, this would normally be expected to start an interaction dialog with the user when not being authenticated yet, not remember the authenticated identity in the session if the user happens to be authenticated (the fact this happens to work on JBoss seems more like a coincidence than something that is supposed to happen).
That all said, section 13.10 of the Servlet spec does allow containers to create an HTTP session:
Containers may create HTTP Session objects to track login state. If a
developer creates a session while a user is not authenticated, and the
container then authenticates the user, the session visible to
developer code after login must be the same session object that was
created prior to login occurring so that there is no loss of session
information.
(emphasis mine)
But... it's not overly clear if this text is in regard to calling the login() method or the authenticate() one.
In short, this is one of the many small gaps in the Java EE security spec; it's just not defined how to programmatically do a login with a given username/password and explicitly say if you want or do not want that to be for the current request only or for the remainder of the HTTP session.
We hope to fix issues like this in the Java EE Security API (JSR 375) for Java EE 8.
The answer is that after invoking httpServletRequest#login(String, String) you should still invoke httpSevletRequest#authenticate(HttpServletResponse). My final, working code, is:
httpServletRequest.login(loginRequest.getUsername(), loginRequest.getPassword());
httpServletRequest.authenticate(httpServletResponse);
As you want programmatic authentication, there is no need of <login-config> in web.xml
I have a web app running on Tomcat 7, and I've successfully gotten SSL and form-based authentication to work by using https and the appropriate port directly. However I'd like to require SSL for the login page and can't seem to get this to work if I navigate to the root of my web app. E.g. if I go to http://localhost:8080/ProjectManagementSystem/login.html it redirects to SSL, but not if I go to http://localhost:8080/ProjectManagementSystem The latter does redirect to the login page but doesn't change to SSL.
Is this possible without moving the login page to its own directory (as in this question)?
The relevant pieces from web.xml are:
<security-constraint>
<web-resource-collection>
<web-resource-name>PMS</web-resource-name>
<url-pattern>/login.html</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>ProjectManagementSystem</realm-name>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>
I've tried a number of different configurations (e.g. adding additional url-patterns like /) but can't get anything to redirect when I go to the web-app's root. I'd really appreciate knowing if this is impossible or if I'm just doing something wrong. Thanks.
ETA: I actually went ahead and tried moving login.html to login/login.html and changing it to <url-pattern>/login/*</url-pattern> and it still doesn't work. So I think I must be doing something wrong, but I can't for the life of me figure out what.
ETA2: I also tried <url-pattern>/*</url-pattern> and <url-pattern>*</url-pattern> and <url-pattern>*.html</url-pattern> and none of these worked either...
ETA3: I tried changing the web-resource-name as well, in case it was conflicting with another part of the web.xml, but that still didn't work. I'm about out of ideas.
I got this to work in JBOSS 7.1.1 as follows:
<security-constraint>
<web-resource-collection>
<web-resource-name>*</web-resource-name>
<url-pattern>/logon.jsp</url-pattern>
<url-pattern>/logonReconnect.jsp</url-pattern>
<url-pattern>/logoff.do</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
E.g. there were 3 pages allowing logon, together with SSL configuration in standalone.xml this forces SSL for the log on pages and session but does not place a constraint on other content. This was to address a kind of bizzre problem in IE8 and earlier where active content (hotspots) was disabled if we placed the constraint on all content.
I had the same problem: Only the root page did not redirect to https, all other pages did. I managed to fix it by using TWO url-patterns in the security-constraint like
<security-constraint>
<web-resource-collection>
<web-resource-name>PMS</web-resource-name>
<url-pattern>*.xhtml</url-pattern>
<url-pattern>/</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>