Is it possible to somehow copy glassfish File Realm configuration (that is - users with stored passwords) between glassfish installations?
I thought all the required user info was contained within keyfile file, however that's not the case. As far as I can tell passwords are hashed with some salt added (different hash is generated each time for the same password) and as a result after copying to another installation they no longer work.
Would it be possible to maybe copy the salt info, wherever it is stored? Or find out what the salt is and generate SHA hash manually? Or is the problem somewhere else entirely?
I know I could use asadmin to simply generate it again at each installation, but that is another step in the process, and I am already copying other parts of configuration (like domain.xml).
I have migrated the keyfile between Glassfish versions such as Glassfish4.1 to Glassfish4.1.1 and even to Payara41 without any problems, often.
Depending on your <security-role> and <security-constraint> settings, you may also have to ensure that this is set in the admin console:
[x] Default Principal To Role Mapping Enabled
This is under:
Configurations > server-config > Security.
Be sure to use server-config not default-config.
If you are using the same web app on the newer/other Glassfish server you probably have something like the following anyway; In any case if you are doing FORM authentication against the file realm you'll need this in web.xml:
<!-- JAAS FORM authentication: j_security_check -->
<login-config>
<auth-method>FORM</auth-method>
<realm-name>file</realm-name>
<form-login-config>
<form-login-page>/login.xhtml</form-login-page>
<form-error-page>/error.xhtml</form-error-page>
</form-login-config>
</login-config>
Related
Our application server (Apache Tomcat Plume) that use jta-managed data source through tomee.xml file should access database server just in secure (HTTPS) mode with two way ssl or client authentication.
So we have to put keystore and truststore plain passwords into setenv.sh or other places in row format. (I m not sure that is the first and last method to do that?) and what happens is tomcat logging mechanism log all these secret information in plain format into log files like catalina.out.
That what (locating raw passwords in config files) is we do not want. Actually we must ( although it s not appear a big threaten while user have access to files, could find real password atleast), encrypt password and use it in environment variables.
Central Question
In other word, how can we set jvm properties and environment variables in encrypted mode?
Re: Hide or disable Tomcat command line arguments logging (the title of this question)
This logging is done by VersionLoggerListener it is possible to configure it, or just remove it from configuration (server.xml).
Re: plaintext passwords handling
This is covered in Tomcat FAQ.
A Vault can be used to store secrets.
I currently have a server.xml configuration which has the following in it
<Resource auth="Container"
description="DB Connection"
driverClass="oracle.jdbc.driver.OracleDriver"
maxPoolSize="40"
minPoolSize="2"
aquireIncrement="1"
name="jdbc/FOOBAR"
user="foo"
password="bar"
factory="org.apache.naming.factory.BeanFactory"
type="com.mchange.v2.c3p0.ComboPooledDataSource"
jdbcUrl="path:to:db:port:db" />
I have a requirement to no longer allow the username/password to be in clear text in the server.xml file for obvious reasons.
I've read a bit online and came across How to Secure Tomcat Database Passwords for Java
Encrypt username and password for JNDI in Tomcat Server.xml and many other pages; however, I'm a bit stuck.
I first looked at extendind the BasicDataSourceFactory - but it seems that can't occur due to my using c3p0 CombinedPooledDataSource. I then looked at trying to create a c3p0 datasource wrapper by implementing PooledDataSource, Serializable and Referenceable but that didn't work either.
I read I could move the authentication to the server side by making auth="Container" => auth="Application". However, I'm not sure of how to implemet the rest of the pieces with my using Hibernate.
Any help would be great.
So, this will not be a high-security solution.
But an easy way around this is to make use of the fact that c3p0's "password" property is just a configurable c3p0 property, which can be set in a wide-variety of ways. So, you could create a c3p0.properties file and/or a c3p0-config.xml file, and set the password there. Alternatively, you could make sure that a System property c3p0.password is set when you run the JVM.
If you'll have multiple DataSources with different passwords, you'll need to use c3p0's named config feature, which means a c3p0-config.xml file.
c3p0 config (both c3p0.properties and c3p0-config.xml) files can be stuck at the top-level of a jar file in your application's effective CLASSPATH. (With tomcat, you have to be careful about distinctions between the web-app specific ClassLoader and more widely shared locations.) So, you can have your password embedded in a compressed jar file rather than a plain text file. Obviously, this is not secure: plaintext is just an "unzip" away. But it would prevent the password from being casually greppable and such.
Please see http://www.mchange.com/projects/c3p0/#configuration_files
Good luck!
This question is related to Weblogic 12c.
I have an EAR file that I want to deploy in various environments (dev, QA, pre-prod and prod). However, my application requires a username and a password (to connect to another server) and they're not the same across the four environments. I don't want to package 4 different property files in 4 different EAR files. I want a single generic EAR file. Beside, I don't want to handle the prod password during packaging.
Ideally, I'd like the admin of each environment to provide the appropriate username nad password for the environment. Unlike Tomcat, Jetty or JBoss(?), I think it's not possible for a WebLogic Admin to specify this information in a way that it will become available under the java:comp/env JNDI context.
How can an application obtain some admin-defined configuration strings from Weblogic?
BTW, it's not a username/password for a JDBC connection.
From what I understand, you need to change parameters based on the environment you are using right?
If you would like to override parameterss on the fly you can use WebLogic deployment plan concept.
Did you mean that you need to provide username/password to start-up the application?
If so, you may accomplish that by creating a script with WLST http://docs.oracle.com/cd/E15051_01/wls/docs103/config_scripting/using_WLST.html
As far as I know, the WebLogic way is to
Define your username/password as env-entry in the deployment descriptor
Deploy your application together with the plan.mxl whereas each environment admin maintains his own envrionemnt-specific version of the plan.xml
That way you get them into /comp/env/config
More details here: http://docs.oracle.com/cd/E11035_01/wls100/deployment/config.html
Only drawback known to me: plan.xml will always contain the unencrypted password but as the admin knows the password anyway and this is "his" file on "his" maschine that should be fine.
In Visual Studio 2012, using publish profiles along with web deploy simplifies the deployments quite a bit. However it still is missing few things or may be I don't know how to use it yet.
I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can this be done? If I leave the username and password empty, I am prompted for it. Is there a way like manually modifying the .pubxml files?
Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in PublishProfileName.pubxml.user that is local to each user? I could at least save the username but obviously don't want that to be checked in.
The Configuration itself is not part of PublishProfileName.pubxml but is stored in PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
Same for the Platform as last point.
I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.
EDIT
The command line that works fine for publishing is
MSBuild.Exe MyProject.sln /p:Configuration=QA /p:DeployOnBuild=true;PublishProfile=PublishToQA;AllowUntrustedCertificate=true /p:authType=NTLM /p:UserName=
In this I would like to omit the /p:Configuration=QA if the configuration becomes part of the publish profile itself.
Some answers to your questions.
I prefer to use the NTLM authentication without storing the username and password (especially) in the publish profiles. How can
this be done? If I leave the username and password empty, I am
prompted for it. Is there a way like manually modifying the .pubxml
files?
Your authentication is typically driven by how Web Deploy is hosted. By default if you are using the Web Management Service then you are using IIS users for auth. With IIS users you can control which users have permissions to specific sites/apps. You can configure WMSVC to use windows auth as well though. If you have issues using VS for those scenarios let me know.
If you are using the Remote Agent service to host Web Deploy then in this case you'll be using windows auth.
Why is the username/password stored in PublishProfileName.pubxml that I have checked in the source control and not in
PublishProfileName.pubxml.user that is local to each user? I could
at least save the username but obviously don't want that to be checked
in.
We have another mechanism for you to determine what information is private/shared. With the exception of the password all publish info is shared (and checked in by default). In order to simplify the design you can either have a publish profile which is shared, or one which is not shared at all. There is no in-between in which you have a profile that some fields are shared and other not. Password is special cased here and encrypted on a per-user/per-machine basis in the .pubxml.user file.
If you'd like to have a private publish profile then you can simply not check in the .pubxml file which corresponds to the publish profile. These are stored in the Properties\PublishProfiles (or My Project\PublishProfiles for VB) and just exclude them from the project and don't check the files in. The publish dialog looks for the profiles on disk, not just the ones which are in the project. Everything should continue to work.
We don't support the concept of selectively storing values in the .pubxml.user file. The publish dialog will only store a set number of values in that file. Instead of
The Configuration itself is not part of PublishProfileName.pubxml but is stored in
PublishProfileName.pubxml.user as LastUsedBuildConfiguration.
Same for the Platform as last point.
This was a mistake it should have been stored in the .pubxml file, not the .pubxml.user file. We have since fixed this, but haven't had a chance to release the update yet.
The Configuration property cannot be set in the publish profile. The Configuration property is a core part of the build process. To be more specific, the reason why we didn't call this property Configuration is because the .pubxml file is imported into the definition of the .csproj/.vbproj during a build & publish. Since other properties are defined based on Configuration you cannot change the value once it's been set. I just blogged with way too much detail on this subject at http://sedodream.com/2012/10/27/MSBuildHowToSetTheConfigurationProperty.aspx. This limitation is an MSBuild thing not a publish limitation. For command line you should specify Configuration in the following way:
msbuild.exe myproj.csproj /p:...(other properties)... /p:Configuration=
I am also missing support for multi-server deployments. I am currently forced to use batch files in addition to Publish Profiles.
We don't have direct support for this, but if you expand on your needs I may be able to help. FYI I have an extension which you may be interested in. I have posted a 5 min video to http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx.
You are free (and encouraged) to manually edit your pubxml files, so feel free to remove the password.
To switch to NTLM, change AuthType to NTLM in the first PropertyGroup.
Platform and Configuration remain build configuration, the user file just stores them so Visual Studio knows what the last configuration you deployed was.
By multi-server, do you mean a web farm? If so, you might try looking at the Web Farm Framework which basically performs MSDeploy syncs from the primary server to the others.
Alternatively, you could switch to the command line and use postSync to upload and execute a batch file on the remote server that triggers the other deployments from there.
I have an Artifactory repo that sits behind basic authentication. How would I configure the settings.xml to allow access?
<mirrors>
<mirror>
<id>artifactory</id>
<mirrorOf>*</mirrorOf>
<url>https://myserver.example.com/artifactory/repo</url>
<name>Artifactory</name>
</mirror>
</mirrors>
<servers>
<!--
This server configuration gives your personal username/password for
artifactory. Note that the server id must match that given in the
mirrors section.
-->
<server>
<id>Artifactory</id>
<username>someArtifactoryUser</username>
<password>someArtifactoryPassword</password>
</server>
So server tag is the user credentials for the artifactory user, but I also need to provide another user/password to get through the basic-auth. Where would I put that?!?
The username and password go in the server settings as you have them. I think your problem is that you've specified the server by its name (Artifactory), rather than its id (artifactory).
I'd recommend you put the server settings in your user settings rather than the global settings. You can also encrypt the password in Maven 2.1.0+, see the mini guide for details.
Update: What version of Artifactory are you using? There is a discussion and corresponding issue that basic-auth fails. This has apparently been fixed in 2.0.7 and 2.1.0.
From the discussion, it seems that a workaround is to pass the properties via the command line, e.g.
-Dhttp.proxyHost=proxy -Dhttp.proxyPort=8080 -Dproxy.username=... -Dhttp.password=...
Update: To let your Maven installation connect through a firewall, you'll need to configure the proxy section of the settings.xml, see this question for some pointers on doing that.
Update2: There are additional properties you can set in the server settings, see this blog for some background. I've not had an opportunity to test this, but from the blog and related http wagon javadoc, it appears you can set authenticationInfo on the server settings, something like this:
<server>
<id>Artifactory</id>
<username>someArtifactoryUser</username>
<password>someArtifactoryPassword</password>
<configuration>
<authenticationInfo>
<userName>auth-user</userName>
<password>auth-pass</password>
</authenticationInfo>
</configuration>
</server>
I was able to use the following configuration to enable HTTP basic authentication - by writing the necessary HTTP headers manually. In my situation I used it to access the build artifacts on my Go server as a poor man's staging repository.
<server>
<id>go</id>
<configuration>
<httpHeaders>
<property>
<name>Authorization</name>
<!-- Base64-encoded "guest:guest" -->
<value>Basic Z3Vlc3Q6Z3Vlc3Q=</value>
</property>
</httpHeaders>
</configuration>
</server>
Tip to solve the problem with the clear text password:
Access and login into Artifactory.
Once you are logged in, click over your user name, on the superior right corner of the screen.
Put your password then clique in the em Unlockbutton, enabling the encrypted password.
Copy the tag that will be showed on the inferior part of the screen and paste it into the settings.xml file. If you prefer to just copy the password, be sure about let it exactly equals the tag showed below, including the "\" at the beginning of the password.
Remember to adjust the tag with the id of your server, defined into the tag, in your POM.xml
Click in Update button and ready! Check if everything will occur well at the next project's publication.
Most of the time this happens due to following reasons
Settings.xml is not found inside the ~/.m2/conf or ~/.m2 directories
Settings.xml doesn't contain the correct credentials Username or the API Key to access the Artifactory
Cannot access the Artifactory mentioned in the Settings.xml with the given credentials
You can see what Maven looks for in what directories... Running with -e -X options will show these details
Sometimes the Settings.xml file may be placed inside a different directory, so when you build locally, maven cannot find it inside ~/.m2 or ~/.m2/conf directories. For e.g if the project uses buildkite, it may be inside a directory that buildkite can access during the build process. In that case, just copy the same Settings.xml file into ~/.m2.
To find the aritifactory, logon to the url using your email/password and go to profile and locate the username and the API Key like in the pic.
Then check the repository is correct in Settings.xml