I need help with using keycloak in an Errai app. I am getting an error about "unknown authentication method" for "KEYCLOAK" ? I have the keycloak-appliance running (on a different port though), and the Errai app has a with KEYCLOAK in the web.xml file inside WEB-INF
When I run the Errai app with mvn gwt:run, I get : RuntimeException caused by "Unknown authentication mechanism KEYCLOAK". I have no idea how to go around this issue .
Just wanted to add a little more detail to #cfsnyder's answer. In order for your application server to recognize a definition in the web.xml that looks like this:
<login-config>
<auth-method>KEYCLOAK</auth-method>
<realm-name>internal</realm-name>
</login-config>
you'll need to tell jboss (in this instance) how to interpret that particular auth method. At the time of my answer, this is in section 8.2 of the Keycloak docs.
First, download the keycloak adapter (remember, this is not the same as the Keycloak Server). Next, unzip the download in the wildfly home directory. With your application server running, just use the following command to install the Keycloak configuration into the appropriate files:
jboss-cli.sh -c --file=adapter-install.cli
When this script completes, your configuration file will have the new entry added to accommodate the KEYCLOAK entry in your web.xml. The script will add something like this to either a domain.xml or standalone.xml:
<security-domain name="keycloak">
<authentication>
<login-module code="org.keycloak.adapters.jboss.KeycloakLoginModule" flag="required"/>
</authentication>
</security-domain>
Once you have the Keycloak module files provided by the adapter + the security domain configuration to link the KEYCLOAK method to the appropriate LoginModule, you should be all set.
You will need to install and configure the Wildfly adapter in order for your Errai app to recognize the "KEYCLOAK" authentication method. See section 7.2 of the Keycloak documentation.
To add to #josh-cain's answer, you might also need following additions in your domain.xml or standalone.xml:
To <extensions></extensions>, add:
<extension module="org.keycloak.keycloak-adapter-subsystem"/>
To <profile></profile>, add:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1"/>
The adapter installation cli scripts can fail for various reasons so you might need to add these entries manually.
Related
Sorry for this naive question.
I generated a project using start.camunda.com, with spring security.
I do see spring security pwd in console. When I try to use admin/, I get a message password is invalid. Should I use some other userid/pwd?
The starter
The app config:
The cmd line spring security pwd
Login fail
a) On the form-based login page provided by Spring Boot you can use the generated credentials as you tried above and as described here:
https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#servlet-hello-boot-dependencies
In you example above this would be:
user: user
password: the generated password you highlighted on the console
b) This gets you past the spring security login, but the project would still be missing the SSO config for Camunda. To make this work quickly you can copy the packages
config
filter
from
https://github.com/camunda-consulting/code/tree/master/snippets/springboot-security-sso/src/main/java/com/camunda/demo
c) if you copy those folders into the generated starter project then the package name will differ, so you need to adjust
com.example.workflow.config.WebAppSecurityConfig line 33
to reflect the changed package name:
filterRegistration.setInitParameters(Collections.singletonMap("authentication-provider", "com.example.workflow.filter.webapp.SpringSecurityAuthenticationProvider"));
d) as a result of the new security configuration the credentials from a) will not exist anymore. Instead you can now use the credentials defined in
com.example.workflow.config.SecurityConfig
For instance access http://localhost:8080/ using the credentials john/john or demo/demo
Also see: https://camunda.com/best-practices/securing-camunda/
I want to construct a 2 factor authentication system using freeRADIUS for proxy and privacyIDEA for authentication in server. I read some documents about freeRADIUS and privacyIDEA, and find that rlm_rest module could be helpful for this. I find this document in privacyIDEA webside:
http://privacyidea.readthedocs.io/en/master/application_plugins/rlm_rest.html#rlm-rest
and it just show how to install rlm_rest module in Ubuntu using apt-get, but my server is CentOS 7. So my first question is:
How to install the required packages of rlm_rest module in CentOS?
After that ,the document shows the configuration steps:
The authentication type needs to be configured in the /etc/freeradius/users file:
DEFAULT Auth-Type := rest
and the site configuration should invoke the module as follows:
authenticate {
Auth-Type rest {
rest
}
digest
unix
}
And I don`t know where I should invoke the “authenticate {…}”module? Does it should be write in /etc/freeradius/users ? This is my second question.
Could you please give me some advice or some references? Any help will be appreciate.
The authenticate section goes to your site configuration.
Also on CentOS this would be located in /etc/raddb/sites-enabled, which is linked to sites-available.
You should consider using the rlm_perl module, since this is more flexible.
http://privacyidea.readthedocs.io/en/master/application_plugins/rlm_perl.html#rlm-perl
NOTE: If you want to see the behaviour of this demo app, just go to www.collaborativepowernowinternational.us. Here, select the testssl.PersonController, and you may create a person. Then go and edit the person, where the SSL channel is designated, which will give a redirect loop.
It seems like with Jetty 9 more configuration items went into the start.ini file, I have version 9.05.
In order to test the most basic SSL/https, I am uncommenting the following lines in start.ini:
#===========================================================
# SSL Context
# Create the keystore and trust store for use by
# HTTPS and SPDY
#-----------------------------------------------------------
jetty.keystore=etc/keystore
jetty.keystore.password=OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4
jetty.keymanager.password=OBF:1u2u1wml1z7s1z7a1wnl1u2g
jetty.truststore=etc/keystore
jetty.truststore.password=OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4
jetty.secure.port=8443
etc/jetty-ssl.xml
#===========================================================
# HTTPS Connector
# Must be used with jetty-ssl.xml
#-----------------------------------------------------------
jetty.https.port=8443
etc/jetty-https.xml
No other Jetty configuration changes. I then built the most basic Grails app (has a Person class) where I set certain controller actions to secure, which works fine on my development machine using an older built in Jetty version (that Grails includes). This is done simply by including spring-security-core and then adding the following lines to a configuration file:
grails.plugins.springsecurity.secureChannel.definition = [
'/person/list': 'REQUIRES_INSECURE_CHANNEL',
'/person/delete/**': 'REQUIRES_SECURE_CHANNEL',
'/person/edit/**': 'REQUIRES_SECURE_CHANNEL',
'/person/show': 'REQUIRES_INSECURE_CHANNEL'
]
grails.plugins.springsecurity.portMapper.httpPort=80
grails.plugins.springsecurity.portMapper.httpsPort=443
When I access the person/edit action I get a redirect loop in the browser (using deployed WAR file to Jetty 9 on dedicated CentOs 6 machine). This is using the provided keystore that comes with Jetty 9, just uncommenting the lines in start.ini to use it.
The main Jetty SSL configuration page I'm reading is here. What isn't clear to me is, is updating the start.ini file enough? If not, how exactly does one add the lines in jetty-https.xml described in this previous link, i.e. the lines:
<New id="sslContextFactory" class="org.eclipse.jetty.util.ssl.SslContextFactory">
<Set name="KeyStorePath"><Property name="jetty.home" default="." />/etc/keystore</Set>
<Set name="KeyStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
<Set name="KeyManagerPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
<Set name="TrustStorePath"><Property name="jetty.home" default="." />/etc/keystore</Set>
<Set name="TrustStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
</New>
Not sure how to add them, but they also seem a duplicate of the start.ini file lines above.
Can you please help help me get the most basic Jetty SSL running? Thanks much.
If not familiar with Grails, one can simply download it, then create a domain class -- there is a command line option for this. Then give it fields String firstName, String lastName. Then there are commands to generate a controller and views for it -- this is all totally automatic. Then one adds the plugin, spring-security-core. In chapter 16/17 of this doc and as I have shown, when lists which controller actions are secure, such as person/edit.
You actually have enough here for just the Jetty portion of this to be working using the default trial keystore we ship in Jetty 9.0.6 distribution.
Simply the blurb you have above is enough to make SSL work within Jetty. I downloaded the 9.0.6 distribution and uncommented those lines and it works. Well, I had to go into the start.d/demo.ini file and remove the last two lines with etc/jetty-ssl.xml and etc/jetty-https.xml because they would get run twice...but I digress.
If you start up Jetty you can navigate to https://localhost:8443 and it will complain about being an untrusted certificate and then load up the jetty distribution page.
Based on that I would say this is likely some sort of grails configuration issue that I sadly don't know the answer too, sorry.
Starting Jetty 9.1, things have changed, and you have to follow the instructions in here for things to look correct, per Jetty developers. Moreover, you are not supposed to change/delete/edit anything in ${jetty.home}'s directories. Here's what you need to do for a self-signed certificate based SSL/HTTPS on Jetty 9.1+:
(a) set up your environment variable $JETTY_HOME to point to where you installed your jetty tar bundle, say /opt/jetty/.
(b) Create a new directory, /tmp/myJettyApp, point it to $JETTY_BASE in your environment.
(c) cd to $JETTY_BASE
(d) Follow instructions in here:
/home/sonny $ cd $JETTY_BASE
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar --add-to-startd=https,http2
(e) Set your port if you'd like:
/home/sonny $ cd $JETTY_BASE;
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar jetty.ssl.port=8444
(f) And now, run jetty:
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar
you will see that HTTPS is running at port 8444. Now, if you want to make jetty listen in the traditional HTTPS port, you have to use sudo to run:
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar jetty.ssl.port=443
/tmp/myJettyApp/ $ sudo java -jar $JETTY_HOME/start.jar
Note that this already does the self-signed certs etc. automagically.
Now, if you want to generate your own self-signed certificate (say, because you want to modify the validity to an arbitrary large or small value, depending on your needs), follow the instructions in here, generate a new self-signed cert using keytool and then place it in $JETTY_BASE/etc/ and modify the $JETTY_BASE/start.d/ssl.ini for jetty.sslContext.keyStorePassword and jetty.sslContext.keyManagerPassword respectively. BTW, for the last two ssl.ini passwords, you can use the obfuscated plain text password you used when you ran keytool or use the plain text ones. If you want to obfuscate them, run {jetty.home} $ java -cp lib/jetty-util-9.3.6.v20151106.jar org.eclipse.jetty.util.security.Password "MyInterestingAndAwesomePassword"
Hope this helps someone.
I tried to run grailsw, but the wrapper cannot connect to download grails-2.2.1-download.zip (creates a 0 byte file instead).
I need to use a proxy server to connect to the internet, where do I configure proxy settings for the Grails Wrapper?
After running grails wrapper, your project directory has a new subdirectory called wrapper, with a file grails-wrapper.properties. You can configure your proxy settings in there, with the following properties:
systemProp.http.proxyHost=
systemProp.http.proxyPort=
systemProp.http.proxyUser=
systemProp.http.proxyPassword=
systemProp.http.nonProxyHosts=
I solved this problem for myself.
It is a two step process
1.a) Back up your JRE_HOME\lib\security folder. This is essential because the below steps might corrupt cacerts file under jre.
1.b) You need to install the ssl public key of Github.com to your local file system. To do that you have to use the InstallCert.java program( Link to InstallCert.java )
It is supposed to be run as java InstallCert github.com
and when it asks to enter cert number you need to enter 1
It will create a file with name "jssecacerts" in the current directory
1.c) But this program will not work because it does not know about how to authenticate with proxy. For this you need the code from SSLSocketClientWithTunneling page
Use the above two and create a program that tunnels through the proxy retrieves the ssl key and writes a file called jssecerts
2) Update your grails.bat with addtional options. Add these options to the %JAVA_EXE% command line. Paste them after %DEFAULT_JVM_OPTS%
-Dhttp.proxyHost=YourproxyURL -Dhttp.proxyPort=YourproxyPort -Dhttps.proxyHost=YourproxyURL -Dhttps.proxyPort=YourproxyPort -Dhttp.proxyUser=YourProxyUserID -Dhttp.proxyPassword=YourProxyPassword -Dhttps.proxyUser=YourProxyUserID -Dhttps.proxyPassword=YourProxyPassword -Djavax.net.ssl.trustStore=path-to-your-jssecacerts-created-in-step-1
I'm using the Grails stack on Heroku to deploy an app. I'd like to be able to serve my app with a root of myapp.herokuapp.com/xyz as opposed to myapp.herokuapp.com, in the same way I'm able to serve from root of localhost:8080/xyz in development. I've tried adding a grails.app.context in Config.groovy like so:
environments {
production {
grails.app.context = "/xyz"
}
}
But it doesn't seem to have an effect in deployment. Do I have to configure something with Heroku? Any ideas?
It looks like you have to add a jetty-web.xml file to the WEB-INF directory to set the context path:
<?xml version="1.0" encoding="UTF-8"?>
<!-- File: web-app/WEB-INF/jetty-web.xml -->
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<Set name="contextPath">/xyz</Set>
</Configure>
If this helps proper credit goes to this site, which was linked from an article on Grails and Heroku by Tomas Lin.
I don't think you can set context path with the current Grails build pack. If you feel like it, you can fork the build pack and hack it to support setting context (see build pack doc for more info on build packs).
Another option is to build your Grails app locally into a WAR file and deploy the WAR file using WAR deployment. The WAR deployment process will use the webapp-runner utility to run your app with Tomcat and it supports configuring the context path. Here's the help output for webapp-runner 7.0.22.3 (what I happened to have installed, might be slightly out of date):
Tomcat Runner runs a Java web application that is represented as an exploded war in a Tomcat container
Usage: java -jar tomcat-runner.jar [arguments...] path/to/webapp
Arguments:
--session-timeout The number of minutes of inactivity before a user's session is timed out
--port The port that the server will accept http requests on
--context_xml The parth to the context xml to use
--path context path (default is /)
--session_manager session store to use (valid options are 'memcache')
--session_manager_operation_timeoutoperation timeout for the memcached session manager. (default is 5000ms)
--session_manager_locking_modeSession locking mode for use with memcache session store. (default is all)
--session_manager_ignore_patternRequest pattern to not track sessions for. Valid only with memcache session store. (default is '.*\.(png|gif|jpg|css|js)$'
As explained in the WAR deploy doc, you can set webapp-runner options for your webapp using the WEBAPP_RUNNER_OPTS config var.