JAAS - isUserInRole returns false for all roles in Tomcat - authentication

Here is the issue,
The JAAS realm connects to the database fine, the user name and password match, the session is authenticated. HOWEVER, none of the roles seem to be getting into the Principal. Tomcat's isInUserRole returns false for every role, and tomcat security doesn't see them either.
Here is the realm configuration in the Server.xml
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="TomcatTimedLogin"
userClassName="com.tagish.auth.TypedPrincipal"
roleClassNames="org.ovasp.java.jaas.RolePrincipal" />
Here is the login.config
TomcatTimedLogin
{
org.owasp.java.jaas.TomcatTimedLogin required
useDS=true
dsJNDI="jdbc/resourceName"
dbDriver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
dbURL="jdbc:sqlserver://server\\DBSERVER;databaseName=DBName"
dbUser="username"
dbPassword="password"
debug=true
loginTable="loginTable"
clippingLevel="3"
interval="10"
loginQuery="SELECT UserID,Password FROM Users WHERE LogonUserName=? AND RetirementDate is null"
rolesQuery="SELECT Role.RoleDescription FROM User_Role,Role WHERE User_Role.UserID=? AND User_Role.RoleID=Role.RoleID";
};
And in catalina.properties I refer to the configuration like this
java.security.auth.login.config=file:///C:/config/login.config
When start the application I do get the following message in the Debug output, not sure why as all classes should be accessible by the server
SEVERE: Class org.ovasp.java.jaas.RolePrincipal not found! Class not added.
Any help would be appreciated. I have already read post after post and tutorial after tutorial, and those who do have this problem, don't have solution posted.
Btw, I am using Tomcat 5.5, not my choice, legacy code, you know how it is! I also using the OWASP login module (OWASPJaasLoginModule.jar). This jar file is located in the server/lib directory.

Okay... I solved it myself... again, VERY STUPID! If this was my code I would be mad at myself, but it is not, and after 4 days of screwing around with this app, I am close to fed up. The problem was that the CLASS is not
org.ovasp.java.jaas.RolePrincipal
its
org.owasp.java.jaas.RolePrincipal
STUPID!!!

Related

How to change password of `admin` account in `flowable-design` for publishing app?

I've installed Flowable 3.6.1 in my localhost. But when I changed the Host configuration in Tomcat folder, I found flowable-design was unable to publish app to flowable-engage.
After tens of times attempts, I found the configuration located at Tomcat/webapps/flowable-engage/WEB-INF/classes/flowable-default.properties as following:
flowable.common.app.idm-url=http://localhost:8080/flowable-work
flowable.common.app.idm-admin.user=admin
flowable.common.app.idm-admin.password=test
So, I changed admin's password here, but it was not working actually. However, I guess the file name was the problem. Then I changed the file name to flowable.properties, it was still not working.
REMEMBER: In Tomcat/webapps/ROOT/index.html, flowable told that username and password in different flowable application is independent. If you want to change admin's password, you had to know which application you are going to apply these changes.
After a long time digging, I finally found the solution to put these three configuration in Tomcat/bin/setenv.bat as following:
set "JAVA_OPTS=%JAVA_OPTS% -Dflowable.common.app.idm-url=http://<domain>/flowable-engage/ -Dflowable.modeler.app.deployment-api-url=http://<domain>/flowable-engage/app-api -Dflowable.modeler.app.undeployment-api-url=http://<domain>/flowable-engage/platform-api/app-deployments -Dflowable.common.app.idm-admin.user=admin -Dflowable.common.app.idm-admin.password=<password>"
And these properties are loaded in flowable-ui-design-conf module, look
at
com.flowable.design.conf.ApplicationConfiguration#basicHttpClientProvider(FlowableCommonAppProperties commonAppProperties) for more information.
Cause I want my flowable-design to be able to deploy app to flowable-engage, so I changed admin's password in flowable-engage.

No MetadataProvider available - shibsp::ConfigurationException

I recently upgraded Shibboleth from versionShibboleth-sp-2.5.6.0-win64 to Shibboleth-sp-2.6.0.0-win64 and Apache web server from 2.4.16 to 2.4.23.
Post the upgrade, when I try to access my application I get the following error:
shibsp::ConfigurationException
The system encountered an error at Fri Oct 14 20:19:51 2016
To report this problem, please contact the site administrator at root#localhost.
Please include the following message in any email:
shibsp::ConfigurationException at (https://xxxxxx.xxxx/)
No MetadataProvider available.
When I access, https:/xxxxx.xxxxx/Shibboleth.sso/Metadata, the metadata file is downloaded and the details seems correct.
Does any one know why does this error occur and how can we solve it?
If it can be of help, I was writing this:
<MetadataProvider type="XML" validate="true" file="/etc/shibboleth/idp-metadata.xml" />
instead of this:
<MetadataProvider type="XML" validate="true" path="/etc/shibboleth/idp-metadata.xml" />
The XML attribute is path. I'm using Shibboleth SP version 3.
Ensure that you have a section in the default as well as an override if there exists. For me, even though there was a section properly created for the override, it needed one in the defaults
Just for the record. Most configuration of your SP takes place in shibboleth2.xml. Locate this file on your server and edit settings to your comfort.
For Linux installations:
Be sure not to edit this file from your installation path, but in your distribution path (i.e. /etc/shibboleth/shibboleth2.xml), otherwise your changes will not be visible ...
A restart of shibd (systemctl restart shibd) is mandatory after changing shibboleth2.xml.
Try the following steps:
1) Go to shar.log and check what is the entity ID returning from the IDP's assertion message.
2) Go to the corresponding IDP'S metadata in SP side, compare both entity ID's.
3) Sure there must be some mismatch between the files, so that's why SP is unable to find the IDP to which it is talking and not able to proceed further.
Finally, update the entity ID in the IDP's metadata and restart shibd. It should work.

SquidGuard Patch (LDAP parsing error)

I have been trying deal with LDAP for my Kerberos Authentication. I have successfully run Kerberos Authentication for Squid and SquidGuard using LDAP (AD). It's working well aside from the user filter function.
squidGuard.log shows the error:
Added LDAP source: internal%5csquidusertest
I have bump on this articlet: http://gotoanswer.stanford.edu/?q=SquidGuard+-+Ldap+doesnt+filter+users
But the hyperlink is no longer working as when you try going to the the main login page, it won't give the ability to register (page is not loading).
I wonder if someone has the copy of that patch.
Thanks in advance.
As I check the compiled package for Debian Wheezy, I can see that the package for squidguard already includes the patch. It might be something on the configuration of my squidguard file.

Read-only web console access in ActiveMQ

I'm using ActiveMQ 5.10 and would like to create a user that has read-only access through the web console.
Red Hat published this article, mentioning that it's not really read only due to a bug in ActiveMQ.
According to the bug report AMQ-4567, the bug is fixed as of ActiveMQ 5.9. However, I'm not seeing it work appropriately.
I have tried a number of different configurations, with the most recent being two separate JAAS implementations, one for Jetty and one for ActiveMQ. The relevant property files are excerpted below.
I can mostly log in to the web console using the "system" user. But the guest user doesn't work at all. The application user (appuser) doesn't need access to the web console at all.
My authN/authZ needs are pretty trivial: one admin user, one application account, and one read-only monitoring account.
Is there any good way to get this working with a recent version of ActiveMQ (>= 5.9.0)?
groups.properties
admins=system
users=appuser,admin
guests=guest
users.properties
system={password redacted}
appuser=appuser
guest=guest
jetty-realm.properties
system: MD5:46cf1b5451345f5176cd70713e0c9e07,user,admin
guest: guest,guest
As an aside, I used the Jetty tutorial and the Rundeck instructions to figure out the jetty-realm.properties file and chapter 6 of ActiveMQ in Action to work out the ActiveMQ JAAS.
I was finally able to get to what I wanted by deploying the web console to an external Tomcat instance. I assume that when it runs out of process, it can't bypass security and so has to use whatever credentials you provide. In this case, I gave the Tomcat instance the read-only JMX user credentials.
It's not great, as there is no security trimmed UI. You can still attempt to create new destinations, delete destinations, etc. When you try with a read-only user, you get an error. That gets a "D" for UX, but a "B" for security.

WebLogic Portal VCR IllegalMonitorStateException connection to JSR-170 Repository

We have recently upgraded from WebLogic Portal 9.2.3 to 10.3.5. We have a JackRabbit repository connected through the Day Software JSR-170 VCR-JCR provider. This has all worked perfectly fine on 9.2.3, but on 10.3.5 we are getting a IllegalMonitorStateException when we try to retrieve content. We have out own facade on top of JackRabbit, that implements the JCR-170. Here is the debug out from the server:
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2b70161: (re)initializing all repo sessions for username: <WLS Kernel>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2bf2311: (re)initializing all repo sessions for username: <WLS Kernel>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: (re)initializing all repo sessions for username: <anonymous>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository():801] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: no session found for repoName=indhold; need to connect
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository():821] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: connect write lock acquired for repoName=indhold
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connectToRepository():875] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: connecting to repositoryName= indhold
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepositoryClass():1503] invoking Class.forName(repoClassName)
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepository():1403] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: Ticket authentication error for: indhold java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:363)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1317)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:745)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepositoryClass(RepositoryManagerDelegate.java:1537)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepository(RepositoryManagerDelegate.java:1327)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connectToRepository(RepositoryManagerDelegate.java:893)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository(RepositoryManagerDelegate.java:832)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connect(RepositoryManagerDelegate.java:1160)
at com.bea.content.federated.internal.delegate.RepositoryHelper.checkCapability(RepositoryHelper.java:759)
at com.bea.content.federated.internal.CapabilityManagerImpl.checkRepositoryCapability(CapabilityManagerImpl.java:57)
at com.bea.content.federated.internal.ManagerImplCapabilityHelper.checkCapability(ManagerImplCapabilityHelper.java:80)
at com.bea.content.federated.internal.ManagerImplCapabilityHelper.verifyCapability(ManagerImplCapabilityHelper.java:54)
at com.bea.content.federated.internal.NodeManagerImpl.getNode(NodeManagerImpl.java:432)
at dk.skat.portal.front.helper.ContentHelper.getNode(ContentHelper.java:1591)
It seems that authenticationn fails, but if I try to set a break-point in the login methods in the repository (our Facade, which doesn't do any authentication challenge, but just wraps JackRabbit, and logs in the same user - "default" - for all access), we are never getting called. Setting the username and password on the Manage Repositories page, doesn't seem to have any effect.
If I on the other hand go to Portal Administration Console, and try to manage or browse the repository, everything works fine, and the login methods are actually called, and the server connects fine to the repository.
This seems very strange. In cetain cases (that happens to happen randomly, we can get the server to all of a sudden get to the repository, but on restart of the server, it is again back to failing).
I've tried to set username/password for the repository to the weblogic user, but that doesn't seem to have any effect, I still get the error.
Furthermore when I've been into the PAC, and logs out, closes the browser, reopen the browser or a completely different browser, the entering of PAC seems to activate the repository to become online (though this is not stable or desired).
Please advice, if there is a bug in WebLogic (it seems it tries to unlock() the ReadLock too many times, resulting in the mentioned exception - should it at all fail on that exception??, Should the lock-count be checked before unlocking?), or if w are doing anything wrong? I can read that there is a known bug in the eclipse tooling for 10.3.5 about exactly this error.
Furthermore, we didn't seem to have any trouble in 9.2.3, what changed in 10.3.5?
Had same issue, found solution here https://forums.oracle.com/forums/thread.jspa?messageID=10984645
In short, it is a product bug, request following patch from Oracle:
WLP Version: 10.3.5
Patch Name/Patch Number/Bug Number: 14377862
Smart Update Patch ID: HPV8