Mule 3.3.1 CE
The SFTP endpoint appears to have problems with user names with the '#' character in them. For example, both of the following fail although the address works in other tools.
<sftp:outbound-endpoint address="sftp://test04#caqa.com:Test1234#testftpdev.caqa.com" outputPattern="#[function:datestamp].xml"/>
<sftp:outbound-endpoint exchange-pattern="one-way" outputPattern="#[function:datestamp].xml" host="testftpdev.caqa.com" port="22" path="/" user="test04#caqa.com" password="Test1234" responseTimeout="10000"/>
The error message is:
Error during login to null#null
com.jcraft.jsch.JSchException: username must not be null.
...etc.
Trying against a site that allows user names without the '#' (e.g., 'test04') seems to work fine through the connector.
Since I have no control over the user names at some of the required target sites, does anyone know of a workaround for this? It needs to run in 3.3.1 CE as we won't be onto 3.4 Enterprise for another couple of months.
You need to URL encode the name and password to take care of this situation.
Related
I am facing a weird problem today, when running my MuleSoft application locally from my AnypointStudio and firing a request from postman, I am getting 403 error. When debugging I found out that the application is checking for flowVars._clientName, however it is missing. According to this documentation, actually yes flowVars._clientName is expected.
https://help.mulesoft.com/s/article/How-to-get-the-client-application-name-in-a-flow-based-on-the-client-id-and-client-secret.
So my application fails with 403 error. Seems that other environments are working perfectly fine.
And yes it is using Client Id enforcement.
Any clues?
Without more details it looks like the issue is inside the logic of your application. The KB article that you referenced is a how to in case you need to obtain the client name. It doesn't say that you have to use for authentication. You don't describe how the application does authentication/authorization. Is it in a flow? Or in a policy? If it is the standard Client ID enforcement policy, the expressions to evaluate client id and secret can be configured, but I don't think the default is not #[flowVars._clientName] nor #[flowVars._clientId].
Note that Exchange is basically a repository of APIs and other artifacts. It doesn't authenticate anything at execution time. Unless your application is trying to use it somehow, but I can't think of a reason for that.
The issue was resolved only by re-downloading Anypoint Studio and mule runtime. Very weird, it was happening only for one application, not for the others. Creating a new workspace did not help, deleting the application and re-cloning and installing did not help, even recloning in a new directory did not help. Only using a new Anypoint Studio and runtime installation resolved it (even with the old code base) ...
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.
While trying to learn how to use the Imap connector in Mule studio, I came across this tutorial. I downloaded it and imported it into AnyPoint studio as a project, and as it were in that tutorial, it worked great (after sending the connector to the right host/port etc.) I then did a quick edit to change the flow to something like this:
IMAP response -> Email to String transormer -> Log this string in the console
And all was well and good. I then went in to the properties of the connector configuration, and changed it so that emails would not be deleted after they're read in, and everything broke. When trying to run the Mule project, I get a long list of errors, starting with:
java.io.IOException: Invalid keystore format
And later down the list:
org.mule.module.launcher.DeploymentInitException: IOException: Invalid keystore format
Which is relentlessly frustrating because really I didn't do anything to the connector's configuration aside from allowing it to keep emails in the inbox of the email that is being used in the IMAP connector. Even if doing something like that were to throw this kind of exception, after changing the configuration back to the way it was when the tutorial was working fine, I still get the same errors and the project fails to deploy.
I suspect that you edited the flow in visual mode instead of XML and that Studio has transformed this (which came from the download):
<imaps:connector checkFrequency="100" doc:name="IMAP" name="imapsConnector" validateConnections="true">
</imaps:connector>
into that:
<imaps:connector checkFrequency="100" doc:name="IMAP" name="imapsConnector" validateConnections="true">
<imaps:tls-client path="" storePassword="" />
<imaps:tls-trust-store path="" storePassword="password" />
</imaps:connector>
i.e. empty tls element(s) got injected thus messing your configuration up.
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 have jetty working with SSL set up, client and server certificates (X.509) provided as required according to Spring Security and upto this it all seems working fine and verified by logs.
Now! The problem is when I access a secure page, client(Chrome) is sending a certificate and server is receiving it successfully but after that it is returning me an empty user. Does any body have any idea what is happening here?
I am providing some information about what I am trying here :
Environment
Windows/Jetty (version: 8.1.11.v20130520)/Spring Security (3.2.0)
Connector in jetty (version: 8.1.11.v20130520)
<connector implementation="org.eclipse.jetty.server.ssl.SslSocketConnector">
<port>9443</port>
<keystore>src/test/resources/server.jks</keystore>
<needClientAuth>true</needClientAuth>
<keyPassword>password</keyPassword>
<password>password</password>
</connector>
Security Configuration file
<sec:x509 subject-principal-regex="CN=(.*?)"
user-service-ref="myUserDetailsService" />
Log extract
09:42:24:214 DEBUG org.springframework.security.web.authentication.preauth.x509.SubjectDnX509PrincipalExtractor (SubjectDnX509PrincipalExtractor.java:43) - Subject DN is 'CN=rod, OU=Spring Security, O=Spring Framework'
09:42:24:218 DEBUG org.springframework.security.web.authentication.preauth.x509.SubjectDnX509PrincipalExtractor (SubjectDnX509PrincipalExtractor.java:58) - Extracted Principal name is ''
The subject-principal-regex you use is wrong. If you want the extracted principal to be rod for the DN in the log message, set the pattern to CN=(.*?), (note the comma at the end). Btw, I think it is the default pattern, so you might as well just skip this setting.
Element <security:x509 /> is used to enable X.509 authentication in spring security.
Attribute subject-principal-regex of element <security:x509 /> is used to provide a regular expression to extract user name out of client certificate.
Regular expression helps in customizing which part do we want to extract out of object of client certificate as our user, like first middle or what ever as specified in regular expression and I was getting null user because of invalid regular expression.
Further more, attribute subject-principal-regex is optional and if we don't provided it explicitly then corresponding class (SubjectDnX509PrincipalExtractor) constrtuctor provides it with following, by default regex "CN=(.*?)(?:,|$)"