Authentication & Authorization
Authentication & Authorization for Sprint 2
This section reflects a revision of the original problem and it's investigation, captured below for historical purposes.
Goal:
Provide authentication and authorization for users of the Platform, who may come in (1) through the GWT web UI or (2) from the R command line.
Approach:
Use two services, an 'authentication' service that verifies user credentials, and a repository service that provides access to Platform resources. Both systems have the same user-ids, but only the authentication service knows about passwords.
Authentication for the Platform
Set-up Crowd running HTTPS.
Add users to a directory linked to Crowd, or to the Crowd database itself.
Add an authentication service, accessed via HTTPS. This service ‘talks’ to Crowd via its REST API over HTTP. The methods are described here:
http://sagebionetworks.jira.com/wiki/display/PLFM/Authentication+and+Authorization+API
Add a filter that applies to all Repository Services calls, which validates the token, passed in the header of the request
Sequence of events:
Authorization for the Platform
High Level Architecture
The service for creating and updating users will both talk to Crowd (via HTTPS) and to the persistence layer via its DAO interface.
Crowd on Amazon Elastic Compute Cloud
AWS notes:
- created an 'm1.small'
- created an EBS volume in the same zone as the server, 'us-east-1c'
Followed instructions to attach volume:http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?using-ebs.html
My server is in
made new volume, in the right 'zone', vol-e47e198c
In 'attach volume' dialog, specified '/dev/sdh'. Nicole's advice is:
in the AWS console choose a mount point of /dev/sdh
log onto the box and run
sudo mount /dev/xvdh /mnt/myNewExternalDrive
(The dialog says "Linux Devices: /dev/sdf through /dev/sdp")
In PuTTY (following http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?using-ebs.html)
yes | sudo /sbin/mkfs -t ext3 /dev/sdh
sudo mkdir /mnt/ebs
sudo mount /dev/sdh /mnt/ebs
downloaded
atlassian-crowd-2.1.1.tar.gz
i.e. the Unix distribution and then uploaded it to
/home/ec2-user/
It takes many minutes to upload.
(I first tried uploading directly to /mnt/ebs but it didn't work.)
sudo cp'd the file to /mnt/ebs
Nicole's advice:
sudo chown -R ec2-user:ec2-user ebs/
gzip -d atlassian-crowd-2.1.1.tar.gz
tar -xvf atlassian-crowd-2.1.1.tar
so the file structure is now:
/mnt/ebs/atlassian-crowd-2.1.1
set crowd.home in the crowd-init.properties file to
/mnt/ebs/crowd-home
** will use the evaluation database for now **
cd'd to
/mnt/ebs/atlassian-crowd-2.1.1
and typed
./start_crowd.sh
it seems to have started up
Also note: I haven't enabled HTTPS yet!
Need to go through these instructions:
http://confluence.atlassian.com/display/CROWD/Configuring+Crowd+to+Work+with+SSL
Now go to
http://ec2-50-17-14-80.compute-1.amazonaws.com:8095
It works!
I then went back to the EC2 console and STOPPED the server
i-c31579af
Note: I did not run the Crowd shut down script first!
Server ID is
BCT7-MZ9X-K8I8-PM3U
generated a demo license and installed
for database, chosen 'embedded' (i.e. demo version)
For 'password encryption' I chose 'atlassian security'.
For email server I used smtp.gmail.com with bruce.hoff and my pw. I left SSL off (which may be wrong).
I bypassed setting up the OpenID integration.
DONE!
http://ec2-50-17-14-80.compute-1.amazonaws.com:8095/crowd/console/login.action
Next steps:
1) Restart and see if I can log in. (May have new server name; may have to restart tomcat.)
2) Enable HTTPS (SSL).
Restarted server
initially there is no public DNS
after a few minutes it's running, with the public DNS name:
ec2-50-16-44-152.compute-1.amazonaws.com
totally different from before!
Tried going tohttp://ec2-50-16-44-152.compute-1.amazonaws.com:8095/crowd/console
but it failed
PuTTY'd into the server:
Ran 'ps', but it showed no Java process running, so I think the server is down.
cd /mnt/ebs successfully, so the ebs seems to still be running.
However, there are no files there and 'df' doesn't show the storage.
So I think the mount was lost.
The AWS console shows that the EBS volume is 'in use' and attached to the instance (i-c31579af:/dev/sdh)
Back in PuTTY:
sudo mount /dev/sdh /mnt/ebs
Now I see the 10GB of space, but the content is gone(!)
Tried detaching and reattaching in the AWS console.
Didn't work. I give up!
Started over, using my sage credentials
- created "Security Group" in the AWS console
with HTTP port 8095 and HTTPS port 8443.
- created a 'micro' instance
"Public DNS" is:
ec2-50-17-17-19.compute-1.amazonaws.com
copied atlassian-crowd-2.1.1.tar.gz to /home/ec2-user
gunzip atlassian-crowd-2.1.1.tar.gz
sudo mv atlassian-crowd-2.1.1.tar /usr/local
sudo tar -xvf atlassian-crowd-2.1.1.tar
sudo chmod -R 777 atlassian-crowd-2.1.1
edited crowd-webapp/WEB-INF/classes/crowd-init.properties
just uncommented the default so
crowd.home=/var/crowd-home
./start_crowd.sh
http://ec2-50-17-17-19.compute-1.amazonaws.com:8095/crowd
resulted in 404 error. So tomcat is running (and listening on port 8095), but Crowd isn't
My guess is that it's a permissions problem.
sudo chmod -R 777 var
stopped/restarted Crowd
Now it works!
Went through the rest of the process of setting up the server.
need to set up the application key/pw pair.
Created 'Generic Application' with user/pw: platform/platform-pw
For the URL I set:http://deflaux-test.appspot.com/
Note that this is NOT https!
'Resolve IP Address' generated 127.0.0.1, which is curious...
Checked "Allow all users to authenticate."
Created a user called 'demouser' with password 'demouser-pw'
Created a group called 'demogroup'.
Create a token
C:\Users\bhoff>curl -u platform:platform-pw -H "Accept: application/xml" -H "Content-Type: application/xml" -v -k -d "<?xml version='1.0' encoding='UTF-8 '?> <authentication-context> <username>demouser
</username> <password>demouser-pw</password> <validation-factors> <validation-factor> <name>remote_address</name> <value>140.107.179.234</value> </validation-factor> </validation-factors> </authentica
tion-context>" -X POST http://ec2-50-17-17-19.compute-1.amazonaws.com:8095/crowd/rest/usermanagement/1/session?validate-password=true
* About to connect() to ec2-50-17-17-19.compute-1.amazonaws.com port 8095 (#0)
* Trying 50.17.17.19... connected
* Connected to ec2-50-17-17-19.compute-1.amazonaws.com (50.17.17.19) port 8095 (#0)
* Server auth using Basic with user 'platform'
> POST /crowd/rest/usermanagement/1/session?validate-password=true HTTP/1.1
> Authorization: Basic cGxhdGZvcm06cGxhdGZvcm0tcHc=
> User-Agent: curl/7.21.0 (amd64-pc-win32) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3
> Host: ec2-50-17-17-19.compute-1.amazonaws.com:8095
> Accept: application/xml
> Content-Type: application/xml
> Content-Length: 295
>
< HTTP/1.1 403 Forbidden
< Server: Apache-Coyote/1.1
< X-Embedded-Crowd-Version: 2.1.1
< Content-Type: text/html;charset=utf-8
< Content-Length: 1423
< Date: Wed, 09 Feb 2011 23:37:14 GMT
<
<html><head><title>Apache Tomcat/6.0.26 - Error report</title><style><!-H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}H2 {font-family:Tahoma,Arial,sans -serif;color:white;background-color:#525D76;font-size:16px;}H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}BODY {font-family:Tahoma,Arial,sans-serif;col or:black;background-color:white;}B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}-></style> </head><body><h1>HTTP Status 403 - Client with address "140.107.149.249", and hostname "140.107.149.249" is fo
rbidden from making requests to the application, platform.</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>Client with address "140.107.149.249", and
hostname "140.107.149.249" is forbidden from making requests to the application, platform.</u></p><p><b>description</b> <u>Access to the specified resource (Client with address "140.107
.149.249", and hostname "140.107.149.249" is forbidden from making requests to the application, platform.) has been forbidden.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/6.
0.26</h3></body></html>* Connection #0 to host ec2-50-17-17-19.compute-1.amazonaws.com left intact
* Closing connection #0
Added the remote address. Now:
C:\Users\bhoff>curl -u platform:platform-pw -H "Accept: application/xml" -H "Content-Type: application/xml" -v -k -d "<?xml version='1.0' encoding='UTF-8 '?> <authentication-context> <username>demouser
</username> <password>demouser-pw</password> <validation-factors> <validation-factor> <name>remote_address</name> <value>140.107.179.234</value> </validation-factor> </validation-factors> </authentica
tion-context>" -X POST http://ec2-50-17-17-19.compute-1.amazonaws.com:8095/crowd/rest/usermanagement/1/session?validate-password=true
* About to connect() to ec2-50-17-17-19.compute-1.amazonaws.com port 8095 (#0)
* Trying 50.17.17.19... connected
* Connected to ec2-50-17-17-19.compute-1.amazonaws.com (50.17.17.19) port 8095 (#0)
* Server auth using Basic with user 'platform'
> POST /crowd/rest/usermanagement/1/session?validate-password=true HTTP/1.1
> Authorization: Basic cGxhdGZvcm06cGxhdGZvcm0tcHc=
> User-Agent: curl/7.21.0 (amd64-pc-win32) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3
> Host: ec2-50-17-17-19.compute-1.amazonaws.com:8095
> Accept: application/xml
> Content-Type: application/xml
> Content-Length: 295
>
< HTTP/1.1 201 Created
< Server: Apache-Coyote/1.1
< X-Embedded-Crowd-Version: 2.1.1
< Set-Cookie: JSESSIONID=07302C98E4992295F04F0FA49BA44B05; Path=/crowd
< Cache-Control: no-cache, no-store, no-transform
< Location: http://ec2-50-17-17-19.compute-1.amazonaws.com:8095/crowd/rest/usermanagement/1/session/OcdmfMhMTeEUmMqaRBLAyQ00
< Content-Type: application/xml
< Content-Length: 422
< Date: Wed, 09 Feb 2011 23:40:10 GMT
<
<?xml version="1.0" encoding="UTF-8 " standalone="yes"?><session expand="user"><token>OcdmfMhMTeEUmMqaRBLAyQ00</token><user name="demouser"><link rel="self" href="http://ec2-50-17-17-19.compute-1.amazo
naws.com:8095/crowd/rest/usermanagement/1/user?username=demouser"/></user><link rel="self" href="http://ec2-50-17-17-19.compute-1.amazonaws.com:8095/crowd/rest/usermanagement/1/session/OcdmfMhMTeEUmMq
aRBLAyQ00"/></session>* Connection #0 to host ec2-50-17-17-19.compute-1.amazonaws.com left intact
* Closing connection #0
Now to get the details for the user:
C:\Users\bhoff>curl -u platform:platform-pw -H "Accept: application/xml" -H "Content-Type: application/xml" -k -X GET http://ec2-50-17-17-19.compute-1.amazonaws.com:8095/crowd/rest/usermanagement/1/us
er?username=demouser
<?xml version="1.0" encoding="UTF-8 " standalone="yes"?><user name="demouser" expand="attributes"><link rel="self" href="http://ec2-50-17-17-19.compute-1.amazonaws.com:8095/crowd/rest/usermanagement/1/
user?username=demouser"/><first-name>demo</first-name><last-name>user</last-name><display-name>demo user</display-name><email>bruce.hoff@sagebase.org</email><password><link rel="edit" href="http://ec2
-50-17-17-19.compute-1.amazonaws.com:8095/crowd/rest/usermanagement/1/user/password?username=demouser"/></password><active>true</active><attributes><link rel="self" href="http://ec2-50-17-17-19.comput
e-1.amazonaws.com:8095/crowd/rest/usermanagement/1/user/attribute?username=demouser"/></attributes></user>
Now to try running from the web:
changed the version in appengine-web.xml to 'repoAndAuth' then ran
mvn gae:deploy
from projects/trunk/services
Result: 'build failure'
mvn gae:run doesn't work either
needed to run: 'mvn gae:unpack'
Now, when I 'mvn gae:run' I can test from localhost:
curl -H "Content-Type:application/json" -H "Accept:application/json" -d "{\"user\":\"demouser\", \"pw\":\"demouser-pw\"}" -X POST http://localhost:8080/repo/v1/session
{"displayName":"demo user","token":"00Cqwht6MS7mmyEiqey2Bw00"}
yeah! Next step deploy:
set deployment to version 'auth' on deflaux-test.appspot.com
ran: mvn gae:deploy
curl -H "Content-Type:application/json" -H "Accept:application/json" -d "{\"user\":\"demouser\", \"pw\":\"demouser-pw\"}" -X POST http://auth.latest.deflaux-test.appspot.com/repo/v1/session
got error, probably because Crowd isn't accepting messages from the app
ping auth.latest.deflaux-test.appspot.com
Pinging appspot.l.google.com [74.125.127.141] ...
Added 74.125.127.141 to allowed list for 'platform' in Crowd.
Still didn't work. Added more debug info, and found that this is the rejected IP: 74.125.75.17
Added the IP to the allowed list. It works!!
curl -H "Content-Type:application/json" -H "Accept:application/json" -d "{\"user\":\"demouser\", \"pw\":\"demouser-pw\"}" -X POST https://auth.latest.deflaux-test.appspot.com/repo/v1/session
Hitting GAE via https also works:
curl -H "Content-Type:application/json" -H "Accept:application/json" -d "{\"user\":\"demouser\", \"pw\":\"demouser-pw\"}" -k -X POST https://auth.latest.deflaux-test.appspot.com/repo/v1/session
!!!!
Now to create a Crowd server that talks SSL:
Created another micro instance
ec2-75-101-179-108.compute-1.amazonaws.com
and followed the earlier instructions to set up Crowd.
BEFORE starting it up, I followed the instructions for enabling SSL:http://confluence.atlassian.com/display/CROWD/Configuring+Crowd+to+Work+with+SSL
I tweaked the Connector element in the apache-tomcat/conf/server.xml file, to add three more attributes,
seen in the existing Connector element.
<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150"
minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
SSLEnabled="true"
keystoreFile="/home/ec2-user/.keystore" keystorePass="changeit"
connectionTimeout="20000" disableUploadTimeout="true" useBodyEncodingForURI="true"/>
Ran
keytool -genkey -alias tomcat -keyalg RSA -sigalg MD5withRSA
which creates /home/ec2-user/.keystore
and I also copied the .keystore file to my desktop ('cause I think I'll need to stick it in my appengine application).
Edited crowd.properties: The instructions say to edit
<Crowd-Home-Directory>/crowd.properties
i.e.
/var/crowd-home/crowd.properties
but this directory doesn't exist yet. I think it's created upon start up.
An educated guess is to edit it here:
/usr/local/atlassian-crowd-2.1.1/etc/crowd.properties
with the expectation that it will ultimately be moved to /var/crowd-home.
But looking at this file I see only " (CROWD)", not the protocol specific URLs.
Made apache-tomcat/bin/setenv.sh
look like
JAVA_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=256m -Dfile.encoding=UTF-8 $JAVA_OPTS -Djavax.net.ssl.keyStore=/home/ec2-user/.keystore
-Djavax.net.ssl.keyStorePassword=changeit -Djavax.net.ssl.trustStore=/home/ec2-user/.keystore -Djavax.net.ssl.trustStorePassword=changeit"
export JAVA_OPTS
Ran /user/local/atlassian-crowd-2.1.1/start_crowd.sh
but I don't see /var/crowd-home
ps doesn't show any Java process running.
One problem is that I entered
disableUploadTimeout="true"
twice in the connector.
After removing the duplicate and running 'start_crowd.sh' again, ps shows a Java process running.
Still hasn't made /var/crowd-home
but log files don't show any errors.
Try going to https://ec2-75-101-179-108.compute-1.amazonaws.com:8443/crowd/console
I had to go through the 'untrusted certificate' warning in Firefox, but it works.
Went through the rest of the server set up.
Note: The settings include a max number of days 'til the user has to change her password.
For now I'm not using this.
Added demouser, demouser-pw
Added application with user/pw: platform/platform-pw
Now let's try to generate a session from curl:
curl -u platform:platform-pw -H "Accept: application/xml" -H "Content-Type: application/xml" -v -k -d "<?xml version='1.0' encoding='UTF-8 '?> <authentication-context> <username>demouser</username> <password>demouser-pw</password> <validation-factors> <validation-factor> <name>remote_address</name> <value>140.107.179.234</value> </validation-factor> </validation-factors> </authentication-context>" -X POST https://ec2-75-101-179-108.compute-1.amazonaws.com:8443/crowd/rest/usermanagement/1/session?validate-password=true
Got the error saying I have to add 140.107.149.249
After adding this address to the 'allowed' list, it works. The response is:
<?xml version="1.0" encoding="UTF-8 " standalone="yes"?><session expand="user"><token>2ffROYdzaeThREyIPbV7Wg00</token><user name="demouser"><link rel="self" href="https://ec2-75-101-179-108.compute-1.a
mazonaws.com:8443/crowd/rest/usermanagement/1/user?username=demouser"/></user><link rel="self" href="https://ec2-75-101-179-108.compute-1.amazonaws.com:8443/crowd/rest/usermanagement/1/session/2ffROYd
zaeThREyIPbV7Wg00"/></session>
Tried running Java app. It fails because I don't have the necessary certificate in Java's keystore.
The documentation seems to indicate that this isn't a problem for appengine's 'fetch' service.
Now try to hit the service, running locally:
curl -H "Content-Type:application/json" -H "Accept:application/json" -d "{\"user\":\"demouser\", \"pw\":\"demouser-pw\"}" -X POST http://localhost:8080/repo/v1/session
ooops it's changed:
curl -H "Content-Type:application/json" -H "Accept:application/json" -d "{\"userId\":\"demouser\", \"pw\":\"demouser-pw\"}" -X POST http://localhost:8080/repo/v1/session
Didn't work: fetch service runs but prints message:
java.io.IOException: Could not fetch URL: https://ec2-75-101-179-108.compute-1.amazonaws.com:8443/crowd/rest/usermanagement/latest/session?validate-password=true
Could it be that my IP address has changed?
It is 140.107.177.53
Yes, that's new! I added it and reran the request:
... with the same result.
Just for fun, try deploying to a new app version called 'ssl'. The test is now:
curl -k -H "Content-Type:application/json" -H "Accept:application/json" -d "{\"userId\":\"demouser\", \"pw\":\"demouser-pw\"}" -X POST https://ssl.latest.deflaux-test.appspot.com/repo/v1/session
fails :^(
Looking at the stack trace in the GAE console, it's rejecting the IP address 74.125.66.80. Added the address in the Crowd application console and reran:
fails :^(
hey, the address changed again, this time to: 74.125.75.1
Added this address .... it worked!!
C:\Users\bhoff\eclipse projects\trunk\services\repository>curl -k -H "Content-Type:application/json" -H "Accept:application/json" -d "{\"userId\":\"demouser\", \"pw\":\"demouser-pw\"}" -X POST https
://ssl.latest.deflaux-test.appspot.com/repo/v1/session
{"displayName":"Demo User","token":"ih9byQiH0m80PbxKY10Byw00"}
Following some advice found on-line, got the desktop application to work as well.
http://www.exampledepot.com/egs/javax.net.ssl/trustall.html
http://stackoverflow.com/questions/2186543/java-secure-webservice
As of 2/28/2011 the Crowd service is running at:
https://ec2-50-16-158-220.compute-1.amazonaws.com:8443/crowd
Using Email with Crowd operating under SSL
When Crowd is configured to serve via SSL it then seems to require SSL authentication with the email server to send email. Below are my notes from getting this to work. The summary of the steps are:
1. Get the public certificate from the server (in our case smtp.gmail.com:465) using a program found here:
http://blogs.sun.com/andreas/entry/no_more_unable_to_find
2. Add the certificates (I found two from the email server) to the keystore being used by Crowd (in my installation it's /home/ec2-user/.keystore) using the 'keytool' utility, documented here:
from http://download.oracle.com/javase/1.3/docs/tooldocs/win32/keytool.html
Details
1) Baseline: execute REST call to SSL-configured Crowd Server
curl -u platform:platform-pw -H "Accept: application/xml" -H "Content-Type: application/xml" -k -d "<?xml version='1.0' encoding='UTF-8 '?> <authentication-context> <username>demouser</username> <password>demouser-pw</password> </authentication-context>" -X POST https://ec2-50-16-158-220.compute-1.amazonaws.com:8443/crowd/rest/usermanagement/1/session?validate-password=true
2) Remove ssl elements from setenv.sh:
- copied setenv.sh to setenv.shBAK
- edited setenv.sh
3) Restart server
From /usr/local/atlassian-crowd-2.1.1
./stop_crowd.sh
./start_crowd.sh
4) Repeat step (1) (expect it to fail):
But it worked!!
5) Try sending mail:
- go to https://ec2-50-16-158-220.compute-1.amazonaws.com:8443/crowd
- can't access your account
- I have forgotten my user name
- enter my email address
- press Continue
IT WORKS!
However I cannot log in to the admin console.
I can verify that the reset-pw link worked by going to the REST API with the new password, which works.
6) Stopped Crowd server and restored setenv.sh file.
Result: I can now log in again!
7) The keyStore and trustStore are both: /home/ec2-user/.keystore
I tried removing the 'trust store' part of the setenv.sh file, leaving just the keystore part.
restarted the server
Result: REST API works, but cannot log in!
8) keytool -list
returns just one entry
keytool -printcert -file gmail.cert.der
seems to work
keytool -import -file gmail.cert.der
... "Certificate was added to keystore"
keytool -list
now returns two entries
changed setenv.sh to use both keystore and truststore; restarted the server. Try to log in:
Result: It works!
Tried to use REST API.
Result: It works!
Tried to send email.
Result: Failed!
I wonder if I'm using the wrong cert, i.e. from gmail.google.com rather than smtp.google.com. Here's another way to do it:http://blogs.sun.com/andreas/entry/no_more_unable_to_find
Ran the InstallCert.java program, looking first at gmail.google.com then at smtp.gmail.com:465.
(Note, I did not install any cert's at this point.)
Result: Each time it listed two cert's. One was the same for both sites, the other was different.
Ran
java InstallCert smtp.gmail.com:465
but got
No errors, certificate is already trusted
Added certificate to keystore 'jssecacerts' using alias 'smtp.gmail.com-2'
need to move to my other keystore!
Tried exporting the cert from the created 'jssecacerts' file
keytool -export -alias smtp.gmail.com-1 -file gmail1.cer
failed, with "Alias ... does not exist."
Aside: There are some related files in
usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/security
and /etc/pki/java/cacerts
the keytool command has a '-keystore' option to refer to a specific keystore rather than the default
So let's export the two gmail certs from jssecacerts:
keytool -keystore jssecacerts -export -alias smtp.gmail.com-1 -file gmail1.cer
keytool -keystore jssecacerts -export -alias smtp.gmail.com-2 -file gmail2.cer
and now import them into /home/ec2-user/.keystore
keytool -import -alias smtp.gmail.com-1 -file gmail1.cer
keytool -import -alias smtp.gmail.com-2 -file gmail2.cer
Restart server
Try logging in at the console. Result: It works.
Try using REST API. Result: It works.
Try sending email. Result: IT WORKS!!!!
Reset password for 'demouser' at console.
Tried logging in using new password via REST API. Result It WORKS!!!
Shortly after I got this working Atlassian chimed in with a solution, which is similar to what I did:
This new error indicates that it is receiving a response, but cannot read it, due to trusted certs. See here for more information regarding this:
http://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services#ConnectingtoSSLservices-Problemsymptoms
You will need to import the SSL certificate from Gmail as outlined here:
http://confluence.atlassian.com/display/JIRA/Using+Gmail+as+a+JIRA+Mail+Server
_________________________________________________________________________________________________
Notes:
Keystore commands, from http://download.oracle.com/javase/1.3/docs/tooldocs/win32/keytool.html
keytool -list
keytool -printcert -file /tmp/cert
keytool -import -alias joe -file jcertfile.cer
This seems to give the solution (simple)!http://g4j.sourceforge.net/faq.html
.. but I it only works to get cert's from web sites, not smtp servers.
Original Problem Formulation:
Goal:
Provide authentication / authorization for users of the Sage Platform.
Authentication: Verify user's identity.
Authorization: Allow a user, or an application invoked by user, to access data in the Platform.
The Platform comprises:
- Addama registry (running on Google App Engine, or "GAE")
- Addama feed service (on GAE)
- Addama file repository service (running on Amazon Elastic Compute Cloud, or "EC2")
- Addama Java Content Repository (JCR) service (on EC2)
- UI html files (on EC2)
- a Google Group
- shared Google Docs
- file repository, hosted at Sage, accessible via Secure CoPy (SCP)
Requirements and Design Constraints:
- Single sign-on. Once a user has signed on to the platform, they don't have to sign into any of the components.
- One-stop user administration: Adding or removing a user in one place will apply to all components.
- "Security at all layers": No component can be part of the platform unless it adheres to (one of) our authentication mechanism(s). (Note, we could implement several mechanisms "under the hood", if the systems we are integrating require it.)
- Platform will have 'arms length' integration with Google Apps, Groups. (I.e. the rest of the system (Addama, Sage file repository) must work if Google tools are omitted.)
- We want to have full control over the UI (hence a custom approach using GWT instead of GoogleSites) but link to the relevant GoogleDocs and GoogleGroups and use the GoogleDocs UI and GoogleGroups UI when folks are interacting with those resources.
Use Cases
- create a google doc, share with the group.
- send a message to the group
- create an analysis, share with the group
- add a user to the platform
- add all users from a collaborating lab to the platform
- create user credentials for a new user, providing access to the platform
- give a user or a group of users access to an addama service
Analysis
There are just four components that need to perform authentication. (The others delegate authentication to the registry.) They are listed here, along with authentication options:
Addama registry GAE application (Google account, Google Apps account, OpenID federated authentication)
Google Apps (Google Apps account, SAML delegated authentication)
Google Group (Google account, Google Apps account)
Sage SSH server (standard unix login)
If the SSH server were eliminated (by migrating the hosted files to an Addama repository service) then a common denominator *might* be Google App account authentication, which in turn might be delegated to an external identity provider.
Design
This is a possible design approach, contingent upon the answers to certain open questions (listed below):
- Restrict the Addama registry application to be hosted on a proprietary domain, configured to authenticate via "Google Apps for your domain".
- Configure Google Apps on our domain to delegate authentication via SAML.
- Configure Google Groups on our domain to delegate authentication via SAML.
- Migrate local file repository to Addama service.
- Employ Atlassian Crowd as the administration console for user authentication.
Open Questions
- Are Atlassians Crowd pricing, license models, and hosting options acceptable for our purposes? Do they prohibit integrating with NextBio?
(Note: Atlassian doesn't host Crowd, rather we download and host it ourselves. It's an Apache Tomcat application, with a variety of choices for databases.)
- What other SAML or OpenID identity provider (ip) tools (provding UIs and/or aggregating other IdP's) are there?
- Can Google Apps and Google Groups use OpenID (instead of SAML) for authentication?
NO. They will authenticate 3rd party app's via OpenID but they do not delegate authentication via OpenID.
-Do we want to use google app's to see content we host elsewhere, or will google app's be the only place that doc's are stored in this 'sprint'?
- Can "Google Group" membership be managed by an external authentication mechanism? YES, it's part of the Google Apps delegation, see below.
- if we are doing "arm's length" integration with google app's, then what other providers should we plan for?
- do we need 'audit logs', e.g. to show when users were added/removed and by whom?
Pivotal assumptions/questions (i.e. that can substantially change the design)
- Does a google doc created outside of the domain need to be able to be shared with a group in the domain?
- Do new users need to be given immediate access to the platform (without an admin in the loop)?
Experiment to address key questions
1. Authenticate Google Apps, Groups using SAML and Crowd
- Set-up Crowd trial edition (on local box or AWS)
- Change Google Apps demo domain to authenticate against Crowd
- Add user to Crowd
-Try to access Google Apps via this user (e.g. make a document)
- try to access Google Groups via this user
2. Authenticate GAE app using SAML and Crowd
- Change/deploy GAE app, authenticating via Google Apps
- Try to log into to GAE app via this user
(If not, can GAE OpenID option work with Crowd or can bypass UserService to use some sort of OpenID connector to reach Crowd?)
3. Authorize using SAML, Crowd
- Define a group in Crowd
- Add a user to a group in Crowd
- Add a user to a group in Google Apps
- See if access to services can be selected based on such group membership.
4. Replace Crowd with Open Source Identity Provider
Repeat 1-3 above.
Experiment execution
Set Up Crowd
- Added 140.107.149.214 deflaux to C:/windows/system32/drivers/etc/hosts on my la top. I can now PuTTY/SSH into 'deflaux' which is a Linux box in Nicole's office.
- Followed http://confluence.atlassian.com/display/CROWD/Installing+Crowd+and+CrowdID
- downloaded zip file
- downloaded and installed WinSCP; connected to deflaux:22 using SCP protocol.
- unzipped zip file and copied contents to /usr/local/tomcat on deflaux
- per the instructions, created the directory /var/crowd-home and edited .../crowd-webapp/WEB-INF/classes/crowd-init.properties accordingly.
- ran sudo ./start_crowd.sh
but got
"The BASEDIR environment variable is not defined correctly. This environment variable is needed to run this program"
- Googled around for a solution. Found