I was able to configure shiro.ini for mariadb. How shall i configure shiro.ini for MongoDB?
I have tried configuring for mariadb, which is working fine.
jdbcRealm = org.apache.shiro.realm.jdbc.JdbcRealm
jdbcRealm.permissionsLookupEnabled = false
jdbcRealm.authenticationQuery = SELECT Password FROM User WHERE Name = ?
ds = org.mariadb.jdbc.MariaDbDataSource
ds.serverName = localhost
ds.user = xxxx
ds.password = xxxx
ds.databaseName = xxxx
jdbcRealm.dataSource = $ds
securityManager.realms = $jdbcRealm
securityManager.sessionManager.globalSessionTimeout = 6000
Unable to get datasource and realm for mongoDB.
You would either need to use a Mongo JDBC lib, or create a custom realm with a Mongo client. There are also a few Shiro Mongo Realms in the community.
Related
I upgraded my webapp with the latest shiro release 1.5.1 and suddenly it doesn't work anymore. Here the log error:
GRAVE: Shiro environment initialization failed
java.lang.NoClassDefFoundError: org/apache/shiro/cache/CacheManagerAware
and here's my shiro.ini that seems to be the culprit:
[main]
jdbcRealm = org.apache.shiro.realm.jdbc.JdbcRealm
jdbcRealm.permissionsLookupEnabled = true
ds = com.mysql.cj.jdbc.MysqlDataSource
ps = org.apache.shiro.authc.credential.DefaultPasswordService
pm = org.apache.shiro.authc.credential.PasswordMatcher
jdbcRealmCredentialsMatcher = org.apache.shiro.authc.credential.Sha256CredentialsMatcher
ds.serverName = localhost
ds.serverTimezone=Europe/Berlin
ds.databaseName = ******
ds.user = *******
ds.password = ********
jdbcRealm.credentialsMatcher = $jdbcRealmCredentialsMatcher
jdbcRealm.dataSource = $ds
pm.passwordService = $ps
jdbcRealm.credentialsMatcher = $pm
shiro.loginUrl = /login.jsp
shiro.postOnlyLogout = true
securityManager.realms = $jdbcRealm
securityManager.rememberMeManager.cipherKey = kPH+bIxk5D2deZiIxcaaaA==
When I go back to the shiro-all-1.4.2.jar version everything is working fine again.
I have even tried to add these 2 lines to my shiro.ini main section but they didn't fix the problem
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager
I can confirm the issue, this should be fixed in the next release.
https://issues.apache.org/jira/browse/SHIRO-749
In addition, the "all" module will likely be deprecated in the future, I'd strongly advise against using them but instead using just the modules you need (for example maybe you just need shiro-web.
The temporary fix is:
a.) also add a dependency to shiro-cache
b.) remove the usage of shiro-all by using the module you need (shiro-web, shiro-guice, etc)
Either way, thanks for the report, we well get this fixed soon!
I have been using JdbcRealm for shiro authentication and authorization, which has been working perfectly. My shiro.ini looks like this:
[main]
authc = org.apache.shiro.web.filter.authc.PassThruAuthenticationFilter
logout = org.apache.shiro.web.filter.authc.LogoutFilter
authc.loginUrl = /login.xhtml
authc.successUrl = /index.xhtml
logout.redirectUrl = /login.xhtml
jdbcRealm = org.apache.shiro.realm.jdbc.JdbcRealm
jdbcRealm.authenticationQuery = select password from useraccount where active = true and username LIKE ?
jdbcRealm.userRolesQuery = select rolename from role where id in(select roleid from userrole where useraccountid = (select id from useraccount where username LIKE ?) and active = true) and active = true
ds = org.postgresql.jdbc2.optional.SimpleDataSource
ds.serverName = dbhost:5432
ds.user = db_user
ds.password = db_pass
ds.databaseName = db_name
jdbcRealm.dataSource = $ds
#.
#.
#.
jdbcRealm.credentialsMatcher = $passwordMatcher
[users]
[urls]
#.
#.
#.
/admin** = authc, roles[Admin]
/activity.xhtml = authc
/item.xhtml = authc, roles[Branch]
/unauthorized.xhtml = authc
When a user role say 'Branch' tries to access a url that is meant for 'Admin', user is safely redirected to '/unauthorized.xhtml'
Things changed however, when I decided to move authentication to Active Directory; shiro.ini looks like this:
jdbcRealm = org.apache.shiro.realm.jdbc.JdbcRealm
jdbcRealm.userRolesQuery = select rolename from role where id in(select roleid from userrole where useraccountid = (select id from useraccount where username LIKE ?) and active = true) and active = true
jdbcRealm.dataSource = $ds
ADRealm = org.apache.shiro.realm.activedirectory.ActiveDirectoryRealm
ADRealm.url = ldap://xxx.xxx.xxx.xxx:389
ADRealm.searchBase = "OU=Company Name,DC=domain,DC=local"
ADRealm.systemUsername= myuser
ADRealm.systemPassword= mypass
ADRealm.principalSuffix= #domain.local
securityManager.realms = $jdbcRealm,$ADRealm
Authentication happens okay, but trying to access the 'unauthorized url', breaks with the error:
[org.apache.shiro.authz.AuthorizationException: LDAP naming error while attempting to retrieve authorization for user [myusername]
How can I make authorization safely redirect to unauthorized url as before, without it breaking? I've even tried this:
authz = org.apache.shiro.web.filter.authz.RolesAuthorizationFilter
authz.unauthorizedUrl = /unauthorized.xhtml
But without success.
Edit
Inshort, how can we configure shiro.ini to return http response 401/3 - (Unauthorized/forbidden) for necessary cases?
It looks like your /unauthorized.xhtml = authc config would block this if you are trying to reuse your 403 page for 401s.
You could probably use: /unauthorized.xhtml = anon (assuming this page didn't need your user context)
I want to know how can we configure chef automate server to use external postgresql database. I have one chef server which is configured with external elasticsearch and postgresql database, now i want to use that same postgresql database in chef automate server. Can somebody tell me how can i achieve that?
Here is my delivery.rb file configuration
delivery_fqdn "192.168.0.101"
delivery['chef_username'] = "delivery"
delivery['chef_private_key'] = "/etc/delivery/delivery.pem"
delivery['chef_server'] = "https://192.168.0.102/organizations/automate_org"
insights['enable'] = true
elasticsearch['urls'] = ['http://192.168.0.103:9200']
elasticsearch['external'] = true
data_collector['token'] = 'helloworld123'
postgresql['version'] = '9.6'
postgresql['external'] = true
postgresql['vip'] = '192.168.0.103'
postgresql['port'] = '5432'
postgresql['username'] = 'admin'
postgresql['superuser_username'] = 'admin'
postgresql['superuser_password'] = 'admin123'
Here is my chef-server.rb
postgresql['external'] = true
postgresql['vip'] = '192.168.0.103'
postgresql['port'] = 5432
postgresql['db_superuser'] = 'admin'
postgresql['db_superuser_password'] = 'admin123'
opscode_erchef['search_provider'] = 'elasticsearch'
opscode_solr4['external'] = true
opscode_solr4['external_url'] = 'http://192.168.0.103:9200'
opscode_solr4['elasticsearch_shard_count'] = 3
opscode_solr4['elasticsearch_replica_count'] = 2
opscode_erchef['search_queue_mode'] = 'batch'
rabbitmq['enable'] = false
rabbitmq['management_enabled'] = false
rabbitmq['queue_length_monitor_enabled'] = false
opscode_expander['enable'] = false
dark_launch['actions'] = false
data_collector['root_url'] = 'https://192.168.0.101/data-collector/v0'
profiles['root_url'] = 'https://192.168.0.101'
Chef Automate server still uses Chef Server, see Automate setup here. delivery.rb is for Automate settings that are non-defaults. The Chef Server settings likely still need set in chef-server.rb, see here, then run chef-server-ctl reconfigure since Automate still stores cookbooks and data in Chef Server.
We have been trying today to put a Cygnus container in production and we haven't been able to connect it to MongoDB. In our case, we have installed MongoDB with the Auth flag, and we created different users in order to test everything work.
However, we didn't find out the way to connect Cygnus. It tries to connect to the sth_default database, but the it requires enough privileges to create other databases.
The workaround was to start the MongoDB service without the Auth flag, allowing us to check that everything worked when the user can access with admin user without login in, which is not the way we would like to work, due to the fact that it is insecure.
Are we missing anything?
Thanks in advance!
UPDATE
I'm adding here the Cygnus agent.conf file. Moreover, I'm using the Docker Image (docker-ngsi: https://hub.docker.com/r/fiware/cygnus-ngsi/) in its latest version.
cygnus-ngsi.sources = http-source
# Using both, Mongo and Postgres sinks
cygnus-ngsi.sinks = mongo-sink postgresql-sink
cygnus-ngsi.channels = mongo-channel postgresql-channel
cygnus-ngsi.sources.http-source.type = org.apache.flume.source.http.HTTPSource
cygnus-ngsi.sources.http-source.channels = mongo-channel postgresql-channel
cygnus-ngsi.sources.http-source.port = 5050
cygnus-ngsi.sources.http-source.handler = com.telefonica.iot.cygnus.handlers.NGSIRestHandler
cygnus-ngsi.sources.http-source.handler.notification_target = /notify
cygnus-ngsi.sources.http-source.handler.default_service = default
cygnus-ngsi.sources.http-source.handler.default_service_path = /
cygnus-ngsi.sources.http-source.interceptors = ts gi
cygnus-ngsi.sources.http-source.interceptors.ts.type = timestamp
cygnus-ngsi.sources.http-source.interceptors.gi.type = com.telefonica.iot.cygnus.interceptors.NGSIGroupingInterceptor$Builder
cygnus-ngsi.sources.http-source.interceptors.gi.grouping_rules_conf_file = /opt/apache-flume/conf/grouping_rules.conf
cygnus-ngsi.sinks.mongo-sink.type = com.telefonica.iot.cygnus.sinks.NGSIMongoSink
cygnus-ngsi.sinks.mongo-sink.channel = mongo-channel
#cygnus-ngsi.sinks.mongo-sink.enable_encoding = false
#cygnus-ngsi.sinks.mongo-sink.enable_grouping = false
#cygnus-ngsi.sinks.mongo-sink.enable_name_mappings = false
#cygnus-ngsi.sinks.mongo-sink.enable_lowercase = false
#cygnus-ngsi.sinks.mongo-sink.data_model = dm-by-entity
#cygnus-ngsi.sinks.mongo-sink.attr_persistence = row
cygnus-ngsi.sinks.mongo-sink.mongo_hosts = MyIP:MyPort
cygnus-ngsi.sinks.mongo-sink.mongo_username = MyUsername
cygnus-ngsi.sinks.mongo-sink.mongo_password = MyPassword
#cygnus-ngsi.sinks.mongo-sink.db_prefix = sth_
#cygnus-ngsi.sinks.mongo-sink.collection_prefix = sth_
#cygnus-ngsi.sinks.mongo-sink.batch_size = 1
#cygnus-ngsi.sinks.mongo-sink.batch_timeout = 30
#cygnus-ngsi.sinks.mongo-sink.batch_ttl = 10
#cygnus-ngsi.sinks.mongo-sink.data_expiration = 0
#cygnus-ngsi.sinks.mongo-sink.collections_size = 0
#cygnus-ngsi.sinks.mongo-sink.max_documents = 0
#cygnus-ngsi.sinks.mongo-sink.ignore_white_spaces = true
Thanks
The following configuration lines are missing:
cygnus-ngsi.sinks.mongo-sink.type = com.telefonica.iot.cygnus.sinks.NGSIMongoSink
cygnus-ngsi.sinks.mongo-sink.channel = mongo-channel
I.e. you have to specify the Java class implementing the MongoDB sink, and the channel that connects the source with such a sink.
If the configuration you are showing is the default one when Cygnus is installed through Docker, then the development team must be warned.
I've created an application and been using Shiro for the authentication.
I've followed most of the guides and also some of the posted questions here regarding shiro and Jdbc Realm.
Here is my shiro.ini file:
[main]
authc.loginUrl=/jsp/loginForm.jsp
authc.successUrl=/test/successUrl.jsp
authc.rememberMeParam = login-remember-me
logout.redirectUrl=/index.jsp
hashService = org.apache.shiro.crypto.hash.DefaultHashService
hashService.hashIterations = 500000
hashService.hashAlgorithmName = SHA-256
hashService.generatePublicSalt = true
hashService.privateSalt = someBase64EncodedSaltValue
realm = org.apache.shiro.realm.jdbc.JdbcRealm
realm.permissionsLookupEnabled = false
realm.authenticationQuery = SELECT password FROM userTable WHERE username = ?
ps = org.apache.shiro.authc.credential.DefaultPasswordService
ps.hashService = $hashService
pm = org.apache.shiro.authc.credential.PasswordMatcher
pm.passwordService = $ps
jof = org.apache.shiro.jndi.JndiObjectFactory
jof.resourceName = java:comp/env/jdbc/theResourceName
jof.requiredType = javax.sql.DataSource
jof.resourceRef = true
realm.dataSource = $jof
realm.credentialsMatcher = $pm
securityManager.realms = $realm
and i'm using the following code in Java to save the password in the database:
DefaultHashService hashService = new DefaultHashService();
hashService.setHashIterations(500000);
hashService.setHashAlgorithmName(Sha256Hash.ALGORITHM_NAME);
hashService.setPrivateSalt(new SimpleByteSource(
"someBase64EncodedSaltValue")); // Same salt as in shiro.ini, but NOT
// base64-encoded.
hashService.setGeneratePublicSalt(true);
DefaultPasswordService pwService = new DefaultPasswordService();
pwService.setHashService(hashService);
this.password = pwService.encryptPassword(password);
Everything looks good and is saving as expected but the problem is when I am logging in. I've traced the execution to JdbcRealm.class and I've seen that the value compared is the "raw string password" and the encrypted password from the database.
Did I miss any step configuring?
To use Salted its better to have seperate salt for every user. So store that salt in database. SEE
Now,
Extend org.apache.shiro.realm.jdbc.JdbcRealm like:
package common.shiro;
import org.apache.shiro.realm.jdbc.JdbcRealm;
public class JDBCSaltedRealm extends JdbcRealm {
public JDBCSaltedRealm() {
setSaltStyle(SaltStyle.COLUMN);
}
}
In shiro.ini:
credentialsMatcher = org.apache.shiro.authc.credential.HashedCredentialsMatcher
credentialsMatcher.hashAlgorithmName=SHA-256
credentialsMatcher.storedCredentialsHexEncoded = false
credentialsMatcher.hashIterations = 500000
credentialsMatcher.hashSalted = true
realm = common.shiro.JDBCSaltedRealm
realm .permissionsLookupEnabled = true
realm .authenticationQuery = SELECT password,salt FROM userTable WHERE username = ?
realm .dataSource = $jof
realm .credentialsMatcher = $credentialsMatcher
securityManager.realm = $realm