I have some services (say S1 & S2) that I would like to connect them with a third party service (say S3) that uses NTLM authentication. My Problem is that I can use either Basic Auth or Oauth. I was wondering if there is a Proxy that can make this Authentication translation (From NTLM to BasicAuth).
|s1|<--|
|--BasicAuth--> |Proxy| <--NTLM--> |s3|
|s2|<--|
For now, I am using Curl (--ntlm) to achieve that, but I would like to alter this as described.
S1 & S2 are running in a Debian Host.
Cheers!
I manage to Solve that by installing Cntlm. It's a proxy that does pretty much what I described.
I configured the proxy as it is mentioned in this blog post
With the main difference that I set only the Domain, and comment in the Password and User arguments:
Domain mySoapNTLMdomain
# Username
# Password
# NOTE: Use plaintext password only at your own risk
# Use hashes instead. You can use a "cntlm -M" and "cntlm -H"
# command sequence to get the right config for your environment.
# See cntlm man page
# Example secure config shown below.
# PassLM
# PassNT
# PassNTLMv2
So I could be authorised by using Basic Authentication. e.g.
curl http://soap.mydomain:1234/my/path --proxy http://127.0.0.1:3128 --user soapuser:andpass --proxy-user soapuser:andpass
Related
I changed mydomain http to https using certbot
and backend side either. (Springboot)
But, I hava a problem. I can not open jenkins page.
it was http://mydomain:9090
I guess it is https problem.
so I would like to change jenkins http to https.
it didn't work.
here is my /etc/default/jenkins:
# defaults for Jenkins automation server
# pulled in from the init script; makes things easier.
NAME=jenkins
# arguments to pass to java
# Allow graphs etc. to work even when an X server is present
JAVA_ARGS="-Djava.awt.headless=true"
#JAVA_ARGS="-Xmx256m"
# make jenkins listen on IPv4 address
#JAVA_ARGS="-Djava.net.preferIPv4Stack=true"
PIDFILE=/var/run/$NAME/$NAME.pid
# user and group to be invoked as (default to jenkins)
JENKINS_USER=$NAME
JENKINS_GROUP=$NAME
# location of the jenkins war file
JENKINS_WAR=/usr/share/java/$NAME.war
# jenkins home location
JENKINS_HOME=/var/lib/$NAME
# set this to false if you don't want Jenkins to run by itself
# in this set up, you are expected to provide a servlet container
# to host jenkins.
RUN_STANDALONE=true
# log location. this may be a syslog facility.priority
JENKINS_LOG=/var/log/$NAME/$NAME.log
#JENKINS_LOG=daemon.info
# Whether to enable web access logging or not.
# Set to "yes" to enable logging to /var/log/$NAME/access_log
JENKINS_ENABLE_ACCESS_LOG="no"
# OS LIMITS SETUP
# comment this out to observe /etc/security/limits.conf
# this is on by default because http://github.com/jenkinsci/jenkins/commit/2fb288474e980d0e7ff9c4a3b768874835a3e92e
# reported that Ubuntu's PAM configuration doesn't include pam_limits.so, and as a result the # of file
# descriptors are forced to 1024 regardless of /etc/security/limits.conf
MAXOPENFILES=8192
# set the umask to control permission bits of files that Jenkins creates.
# 027 makes files read-only for group and inaccessible for others, which some security sensitive users
# might consider benefitial, especially if Jenkins runs in a box that's used for multiple purposes.
# Beware that 027 permission would interfere with sudo scripts that run on the master (JENKINS-25065.)
#
# Note also that the particularly sensitive part of $JENKINS_HOME (such as credentials) are always
# written without 'others' access. So the umask values only affect job configuration, build records,
# that sort of things.
#
# If commented out, the value from the OS is inherited, which is normally 022 (as of Ubuntu 12.04,
# by default umask comes from pam_umask(8) and /etc/login.defs
# UMASK=027
# port for HTTP connector (default 8080; disable with -1)
HTTP_PORT=9090
# servlet context, important if you want to use apache proxying
PREFIX=/$NAME
# arguments to pass to jenkins.
# full list available from java -jar jenkins.war --help
# --javaHome=$JAVA_HOME
# --httpListenAddress=$HTTP_HOST (default 0.0.0.0)
--httpPort=$HTTP_PORT (default 8080; disable with -1)
# --httpsPort=$HTTP_PORT
# --argumentsRealm.passwd.$ADMIN_USER=[password]
# --argumentsRealm.roles.$ADMIN_USER=admin
# --webroot=~/.jenkins/war
# --prefix=$PREFIX
JENKINS_ARGS="--webroot=/var/cache/$NAME/war --httpPort=-1 --httpsPort=9090 --httpsKeyStore=/var/lib/jenkins/jenkins.jks --httpsKeyStorePassword=PASSWORD_SET_ON_CONVERT_TO_JKS"
here is my error page:
errorpage
here is where I refer to(doesn't work):
https://www.vhinandrich.com/jenkins-standalone-ssl-lets-encrypt
actually I didn't user --standalone when I make my ssl certificate.
anyway, what I wanted to do is to enter jenkins site (http or https I don't mind)
please help me.
thanks :)
The error indicates that you are trying to access Jenkins HTTP port via HTTPs. If you want to access via HTTPS you should be calling the SSL port you configured with this flag. --httpsPort=8443.
https://mydomain:8443
Also if you don't want to disable HTTP access simply remove this flag from JENKINS_ARGS --httpPort=-1
Also, you seem to have conflicting ports in your configurations. Use a different port other than the 9090 for HTTPS if you want to use HTTP port as well. You seem to pass --httpPort twice in your configurations. Hence Jenkins is using port 9090 as the HTTP port.
Either change the following property to have a different port or remove the duplicate --httpPort flag and pass --httpPort=-1 to disable HTTP and use 9090 for HTTPS.
HTTP_PORT=8080
I have successfully deployed my Rails app to the Google App Engine (my domain is also hosted by Google), and now I would like to redirect anyone going to my http:// address to my https:// address.
I have found the documentation to do so for a Python app here using the handlers element in the app.yaml file, and have attempted to replicate it in my own.
My app.yaml file now contains this:
handlers:
- url: /.*
script: config/application.rb
secure: always
redirect_http_response_code: 301
However I can still visit http:// without being redirected, and I think that it's because of the script: config/application.rb option that I've passed. I have no idea which file I should use or what that file should contain in a Rails app. Deployment breaks if I do not pass the script option.
Let me know if you need any more info, and thanks in advance for your help!
Well you can enforce SSL through your app's config/environments/production.rb file, you just need to add one line:
Rails.application.configure do
# Other code...
config.force_ssl = true # add this line to force HTTPS on production
end
This will do 3 things for your application, actually:
TLS redirect
Secure cookies: Sets the secure flag on cookies
HTTP Strict Transport Security (HSTS)
Read more about your application's configuration at http://guides.rubyonrails.org/configuring.html
Since Heroku is read-only and does not allow sudo, what do I need to do to be able to install the LetsEncrypt.org certificate on their server for my app?
If I have already set config.force_ssl = true does that matter?
I read the blog post in the first answer here, but I didn't want to pollute my code-base with ACME urls & logic. So I did something similar, but used DNS domain validation ...
With certbot, specify DNS as your preferred challenge:
sudo certbot certonly --manual --preferred-challenges dns
After a couple of prompts, certbot will tell you to deply a DNS TXT record to validate your domain:
Please deploy a DNS TXT record under the name
_acme-challenge.www.codesy.io with the following value:
CxYdvM...5WvXR0
Once this is deployed,
Press ENTER to continue
Your domain registrar probably has its own docs for deploying a TXT record. Do that, and go back to certbot and press ENTER - Let's Encrypt will check the TXT record, sign the cert, and certbot will save it for you to upload to heroku.
See my own blog post for more detail.
Here are two bash functions that you can use to automate the process for you
function makessl {
sudo certbot certonly --manual --rsa-key-size 4096 --preferred-challenges dns -d ${1}
sudo heroku certs:add --type=sni /etc/letsencrypt/live/${1}/fullchain.pem /etc/letsencrypt/live/${1}/privkey.pem
}
function renewssl {
sudo certbot certonly --manual --rsa-key-size 4096 --preferred-challenges dns -d ${1}
sudo heroku certs:update /etc/letsencrypt/live/${1}/fullchain.pem /etc/letsencrypt/live/${1}/privkey.pem
}
They take an arguement for the domain name and as long as you run them from within your heroku app folder you will not have to specify an --app NAME
Example: makessl www.domain.com
Example: renewssl www.domain.com
Combine this is #Eric's answer and you're good to go:
heroku certs:auto:enable
FYI, Heroku now offers automated certificate management w/ Let's Encrypt if you run a paid dyno. You can enable it with:
heroku certs:auto:enable
More info:
https://devcenter.heroku.com/articles/automated-certificate-management
Edit: This answer no longer applies.
It was written before Heroku implemented native support for LetsEncrypt. Leaving the rest for posterity, but this is no longer necessary. Use #Eric's answer now.
Installing the initial certificate
You can use certbot in manual mode to generate the challenge response, modify your site to return that response, then finally complete the certbot manual process.
See this blog post by Daniel Morrison, or the linked answer under Certificate Updates below, for more details.
Certificate updates
As #Flimm mentioned, and as is mentioned in the linked blog post, you'll have to update this every 3 months until Heroku provides better support for LetsEncrypt. You can make that process smoother (no code changes to upload) using an environment variable as described in this answer (Node/Express but the concepts are the same): https://stackoverflow.com/a/40199581/37168
Sabayon
There is a GitHub project that can automate all of this for you by setting your Heroku environment variables. It's a tiny webapp you install as another Heroku app that in turn configures your primary app. I haven't tried it yet but am planning to use it instead of updating my cert next time: https://github.com/dmathieu/sabayon
The default recommendation of Heroku is SSL using Server Name Indication
(SNI), which is free. Since you already obtained your certificate and key, you can add them by:
heroku certs:add <cert>.pem <key>.key
If you need to support legacy browser clients which do not support SNI use the Herkou SSL Endpoint addon which costs $20/mo:
Add that addon by running
heroku addons:create ssl:endpoint
And then add your LetsEncrypt.org certificates:
heroku certs:add <cert>.pem <key>.key
the best way can be to assign the new ssl domain(that starts with https) to your domain which automatically overrides the non-http domain
I created a certbot plugin that uses the Heroku CLI to automate authentication and installation of Let's Encrypt certificates: https://github.com/gboudreau/certbot-heroku
I only have an example that uses the php-nginx Heroku buildpack, but reading that example and finding the equivalent for other buildpacks should be easy enough.
Pull Requests are welcome to help others!
Jenkins and Gerrit have both plugins for OpenID 2.0, but this API has been deprecated by Google May 19 2014 (https://developers.google.com/accounts/docs/OpenID) making it impossible for new installation to use and existing installations must migrate to OAuth2.0(OpendID connect). When trying to use OpenID 2.0 you will get the error message "Error 400: OpenID auth request contains an unregistered domain".
The Gerrit team is aware of the problem but no solution as of yet:
https://code.google.com/p/gerrit/issues/detail?id=2677
Not sure about Jenkins.
Update 2014/11/05: For those coming here the first place read on below. Thanks hans-zandbelt for the feedback. It is incorporated in the updated version. The setup now uses the suggested improvements and only uses mod_rewrite to redirect the gerrit logout url to the right place. Also note that instead of only using the non-domain part of the email the email is used unmodified. This means that if you happen to have an existing setup you need to change username mappings.
For Jenkins do the following:
move ${jenkins_home}/users/youruser to ${jenkins_home}/users/youruser#yourdomain
open ${jenkins_home}/config.xml search "youruser" and replace with youruser#yourdomain
For Gerrit:
either on the machine itself (change GERRIT_HOME to where it is on your machine):
open the sql database with one of the two methods below:
[Recommended] Either through the gerrit command available through ssh:
ssh gerrit.revault.ch gerrit gsql
OR on the machine itself (change GERRIT_HOME to where it is on your machine):
export GERRIT_HOME=/var/gerrit_home
pushd ${GERRIT_HOME}
java -cp $(find . -name "h2*.jar") org.h2.tools.Shell -url "jdbc:h2:file:${GERRIT_HOME}/db/ReviewDB;IFEXISTS=TRUE"
show external
select * from ACCOUNT_EXTERNAL_IDS;
the external ids map your account to different usernames, emails etc.
the ones prefixed with username: e.g. username:test#example.com are for ssh / git login names
the ones prefixed with gerrit: e.g. gerrit:test#example.com are used for the web interface
for a given account_id you can just add new mappings for existing users using sql: e.g.
insert into ACCOUNT_EXTERNAL_IDS values(1000032, NULL,NULL, 'username:test#example.com');
insert into ACCOUNT_EXTERNAL_IDS values(1000032, NULL,NULL, 'gerrit:test#example.com');
Solution
You can use an Apache as a reverse proxy handling authentication for you:
Gerrit
Assuming you already have installed Gerrit and it is listening on address 10.10.10.10:8080.
You will have to configure gerrit to use basic authentication, the [auth] section in your
${gerrit_installation}/etc/gerrit.config should look like this:
[gerrit]
basePath = git
canonicalWebUrl = http://gerrit.example.com
[database]
type = h2
database = db/ReviewDB
[index]
type = LUCENE
[auth]
type = HTTP
emailFormat = {0}#example.com
httpHeader = X-Forwarded-User
[sendemail]
smtpServer = localhost
[container]
user = gerrit
javaHome = /usr/lib/jvm/java-8-oracle/jre
[sshd]
listenAddress = 10.10.10.10:2222
[httpd]
listenUrl = http://10.10.10.10:8080/
[cache]
directory = cache
The username will be in the header X-Forwarded-User. That's how Apache will forward the username
to Gerrit.
On Apache we will use mod_auth_openidc which has support for oauth2. For further information and
example docs refer to https://github.com/pingidentity/mod_auth_openidc. On a recent Ubuntu the installation
looks like this:
sudo aptitude install libjansson-dev apache2 apache2-dev libcurl4-openssl-dev build-essential autoconf libhiredis-dev
git clone https://github.com/pingidentity/mod_auth_openidc.git
cd mod_auth_openidc
./autogen.sh
./configure
make
sudo make install
sudo a2enmod auth_openidc
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod headers
sudo a2enmod rewrite
You will need to add a site configuration e.g. gerrit.conf similar to the one below (you probably want TLS, too) to /etc/apache2/sites-available and activate it with:
sudo a2ensite gerrit.conf
The file /etc/apache2/sites-available/gerrit.conf looks like this:
<VirtualHost *:80>
ServerName gerrit.example.com
ServerAdmin webmaster#localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
OIDCProviderMetadataURL https://accounts.google.com/.well-known/openid-configuration
OIDCClientID <from api console>
OIDCClientSecret <from api console>
OIDCScope "openid email profile"
OIDCRedirectURI http://gerrit.example.com/oauth2callback
OIDCCryptoPassphrase <generate long random passphrase here, no sure if used>
OIDCSessionInactivityTimeout 600
OIDCCookiePath /
OIDCAuthRequestParams hd=example.com
OIDCRemoteUserClaim email
OIDCAuthNHeader X-Forwarded-User
RewriteEngine On
#LogLevel alert rewrite:trace2
RewriteRule ^/logout$ /oauth2callback?logout=http://gerrit.example.com/ [R]
ProxyPass / http://gerrit.example.com:8080/ nocanon
ProxyPassReverse / http://gerrit.example.com:8080/
ProxyRequests Off
AllowEncodedSlashes NoDecode
<Proxy http://gerrit.example.com:8080/*>
# add rewrites here if necessary
</Proxy>
<Location />
AuthType openid-connect
Require claim hd:example.com
Require valid-user
</Location>
</VirtualHost>
In order to get the parameters OIDCClientID and OIDCClientSecret go to the api console under https://console.developers.google.com/project. The credentials are in the context of a project if you haven't one create a project first. E.g. example-it-authentication
On the project go to APIs & auth:
Under APIs activate Google+ API.
Under Credentials, OAuth create new Client ID.
Fill in OIDCClientID and OIDCClientSecret in your apache config (e.g. gerrit.conf)
Under Consent screen fill in email and product name (you will get an error if you don't)
service apache2 restart
You should be done!
Jenkins
Assuming you already have installed Jenkins and it is listening on 10.10.10.11:8080.
For Jenkins the configuration is almost identical. You will need to install and activate the Reverse Proxy Auth Plugin http://wiki.jenkins-ci.org/display/JENKINS/Reverse+Proxy+Auth+Plugin. Under Configure Global Security check the "HTTP Header by reverse proxy" radio.
The default values correspond to the configuration below. You will need to create credentials matching the jenkins hostname in the api console https://console.developers.google.com/project. Report them to your config as before (e.g. jenkins.conf). That should be all.
<VirtualHost *:80>
ServerName jenkins.example.com
ServerAdmin webmaster#localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
OIDCProviderMetadataURL https://accounts.google.com/.well-known/openid-configuration
OIDCClientID <from api console>
OIDCClientSecret <from api console>
OIDCScope "openid email profile"
OIDCRedirectURI http://jenkins.example.com/oauth2callback
OIDCCryptoPassphrase <generate long random passphrase here, no sure if used>
OIDCSessionInactivityTimeout 600
OIDCCookiePath /
OIDCAuthRequestParams hd=example.com
OIDCRemoteUserClaim email
OIDCAuthNHeader X-Forwarded-User
ProxyPass / http://jenkins.example.com:8080/ nocanon
ProxyPassReverse / http://jenkins.example.com:8080/
ProxyRequests Off
AllowEncodedSlashes NoDecode
<Proxy http://jenkins.example.com:8080/*>
# add rewrites here if necessary
</Proxy>
<Location />
AuthType openid-connect
Require claim hd:example.com
Require valid-user
</Location>
<Location ~ "^/(cli|jnlpJars|subversion|whoAmI|computer/[^/]+/slave-agent.jnlp|tcpSlaveAgentListener)">
Satisfy Any
Allow from all
</Location>
</VirtualHost>
Currently there doesn't seem to be support for groups in mod_auth_openidc. If you need groups you can install an LDAP that stores them (but this probably isn't what you want since you are using Google auth) or wait until it is supported by mod_auth_openidc.
Google's OpenID 2.0 has been superseded by OpenID Connect. The Apache module mod_auth_openidc implements OpenID Connect so it can be used in a reverse proxy that fronts Gerrit/Jenkins as described by revau.lt.
However, be aware that relying on the non-domain part of an e-mail address as a unique identifier is insecure unless you restrict logins to a specific domain using the following two configuration settings:
OIDCAuthRequestParams hd=example.com
to skip Google's account chooser screen, and in the <Location> section:
Require claim hd:example.com
to restrict access to only users from the example.com Google domain. If your application is open to any Google account you should not use the e-mail prefix as the primary identifier because you run the collision risk that users in different domains have the same user prefix.
That is why it is better to rely on the full e-mail address, e.g.
OIDCRemoteUserClaim email
or the (opaque) primary identifier that Google uses in the sub claim, e.g.:
OIDCRemoteUserClaim sub
Furthermore, instead of rewriting claims in to headers you can just use:
OIDCAuthNHeader X-Forwarded-User
Migration from OpenID 2.0 to OpenID Connect (retaining OpenID 2.0 user identifiers) is possible to, as described here and here, so you'd use:
OIDCAuthRequestParams openid.realm=<urlencoded-realm-value>
OIDCRemoteUserClaim openid_id
For an exhaustive overview of configuration primitives see: https://github.com/pingidentity/mod_auth_openidc/blob/master/auth_openidc.conf
As I know the fastest way to login into Gerrit with Google account is:
Create Client ID in Google Developers Console
Download this release of Gerrit and Google-OAuth-provider plugin
Re-initialize Gerrit: java -jar gerrit-2.10.1-4-a83387b.war init -d gerrit_site_path
And restart it: gerrit_site_path/bin/gerrit.sh restart
To Jenkins is new Google-login plug-in.
I would like to test my ActionMailer class, but don't have an smtp server. I would like to use gmail to send such emails. Could someone provide a sample with all the necessary configurations both on google and whatever config files in the app?
GMail has only SSL SMTP available, so you should create a SSL SMTP connection through Net::SMTP.
Check this article:
How to use GMail SMTP server to send emails in Rails ActionMailer
I do this with SSMTP. It acts as an SMTP server and proxies to a real SMTP server. On Unix (Ubuntu hardy in this case) it makes the system sendmail work properly.
If you're also on Ubuntu, run apt-get install ssmtp to get it.
This is a sample config file based on mine.
#
# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=postmaster
# The place where the mail goes. The actual machine name is required no
# MX records are consulted. Commonly mailhosts are named mail.domain.com
#mailhub=aspmx.l.google.com
mailhub=smtp.gmail.com:587
# Where will the mail seem to come from?
rewriteDomain=example.com
# The full hostname
hostname=yourhostname.example.com
# Are users allowed to set their own From: address?
# YES - Allow the user to specify their own From: address
# NO - Use the system generated From: address
FromLineOverride=YES
# should turn on SSL & auth to google's SMTP server
# TODO change this user
UseTLS=YES
UseSTARTTLS=YES
AuthUser=yourgoogleuser#example.com.com
AuthPass=yourgooglepassword
You will want to add this to your environment.rb or production/environment.rb:
ActionMailer::Base.delivery_method = :sendmail
ActionMailer::Base.raise_delivery_errors = true