I have Storm working on my own Kerberos realm, but in order to connect to my corporate realm, I'm beholden to their rules. There is only one production AD, so I need to make non-prod and prod versions of all principals. Thus far, I have changed my Storm cluster config to use "storm_np" in non-prod and everything works. (i.e. storm_np#REALM and storm_np/HOST#REALM)
However, the UI seems to always try to run as HTTP/HOST#REALM so I can't get in. Before I changed the principals, I would kinit as HTTP#REALM and I could see the UI just fine. Now, I'm not sure how to (1) tell the UI to run as a different principal and (2) kinit locally so i can get to it
I'm hoping for a property of some kind. To make the "storm_np" changes, I was able to change startup properties and jaas configs. I'd love to find the same for this.
Related
I am trying to migrate wildfly authentication to elytron and got almost everything to work as i want except for one problem.
We are using quartz scheduler to run jobs. These jobs are not bound to a caller principle. Using
SecurityContextAssociation.pushRunAsIdentity(new RunAsIdentity("My_Role", "My_User"));
i was able propagate a princple to following EJB calls. This is not working anymore, the principle is always "anonymous". Is there a way to do the same with Elytron?
Maybe you can use some variation of following:
SecurityIdentity si = SecurityDomain.getCurrent().getCurrentSecurityIdentity();
si.createRunAsIdentity(...);
The current identity needs to have permissions for it to succeed, so if you'll get unauthorized exception you should add RunAsPrincipal permissions to that user: https://developer.jboss.org/people/fjuma/blog/2018/06/01/configuring-permissions-using-elytron-in-wildfly-13
I've installed FusionAuth (awesome product) into a Docker Swarm cluster using the official docker-compose.yml file and everything seems to work brilliantly.
EXCEPT
Periodically, when a user goes to login they will be presented with the above error stating that the search engine is not available. If they try again immediately then everything works correctly! I would, obviously, prefer that they never saw the error.
Elasticsearch is definitely running and is responding to API calls correctly, and I can see the fusionauth_user index is present and populated with docs.
I guess my question is two fold:
1) What role does the ElasticSearch engine play in the FusionAuth ecosystem and can it be disabled?
2) Is there a configurable timeout somewhere that is causing the error message and, if so, where can change it?
I've search the docs for answers to the above but I can't seem to find anything :-(
Thanks for the kind feedback.
1) What role does the ElasticSearch engine play in the FusionAuth ecosystem and can it be disabled?
Elasticsearch provides full text search of user data. Each time a user is created or updated the user is re-indexed. In this case during login, we are updating the search index with the last login instant.
This service is required and cannot be disabled. We have had clients request to make this service optional for embedded applications or small scale scenarios where Elasticsearch may not be required. While this is not currently in plan, it is possible we may revisit this option in the future.
2) Is there a configurable timeout somewhere that is causing the error message and, if so, where can change it?
Not currently.
Full disclosure, I am not a Docker or Docker Swarm expert at all - perhaps there are some nuances to Swarm and response time due to spin up and spin down of resources?
Do you see any exceptions in the log when a user sees this error on the login?
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.
I am testing the tomcat7 clickstack for our application which has some config parameters set using the built in Config features of Cloudbees. The tomcat7 clickstack does not find them, but the standard tomcat6 container does. I have double checked them and reset them through the cloudbees sdk and they are there and correct, but are coming back as null for tomcat7.
The switch to clickstacks requires us to refactor how the servlet container gets configured so that the injection points such as cloudbees-web.xml and jvm system properties behave consistently across all the servlet container clickstacks.
Some of that refactoring has been committed but some of the work is still in my backlog... Assuming none of the other bees steal that task from my backlog before I get to it ;-)
IF I recall correctly, the parameters should be available as environment variables (sub optimal I know, but all containers should be giving this as a consistent UX for all clickstacks, eg both non-java based and java-based) and may be already available as system properties (again sub optimal, but the java container refactoring should be giving this as a consistent UX for all java based clickstacks). The consistent java servlet UX has not been committed yet but should be available soon.
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