Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In principle we can create a collaborative platform including Google Apps, Google Groups,
and Google App Engine authenticating web services (e.g. Addama) in which users experience
single-sign on using their native credentials and externally managed passwords.

Notes

Q: What's the cumulative file size on the Sage SSH server?

A: About 2GB, considering the files in the directory /data/incoming on sage.fhcrc.org

Google Apps provides two APIs to help with authentication:

1. SAML Single Sign-On (SSO) Service: would allow *us* to create and maintain users and groups outside of Google.

http://code.google.com/googleapps/domain/sso/saml_reference_implementation.html

2. Google Apps Provisioning API: would allow us to programmatically create Google users and groups in our private domain.  This would streamline adding users to Google Apps.  If we used it as a total solution, then the non-google app's (e.g. Addama) would have to go to google for authentication, which violates the 'arms length' integration requirement.

3. OpenID sounds like an alternative to SAML:

http://www.google.com/support/forum/p/apps-apis/thread?tid=33a3707bd2ea7904&hl=en

In the case of OpenID, the user may have a Google Account, a Google Apps Account, or an account from any other domain that provides OpenID federated login.

...

Authorize using SAML, Crowd

- Define a group in Crowd: Crowd defines the 'crowd-administrators' group.

- Add a user to a group in Crowd: the user 'bruce.hoff' is in the 'crowd-administrators' group.

- Add a user to a group in Google Apps:  there is a group 'demo' having several members.

- See if access to services can be selected based on such group membership.

Note:  Crowd does not see the google group 'demo'; Google Apps does not see the Crowd group 'crowd-administrators.

This suggests that the group definition component of authorization is not delegated by Google Apps.

The continuation of this experiment is to experiment with control of access via the Google Apps group.

Assuming that Google Apps groups 'authorize' access to Google Apps (doc's, sites, group threads, etc.),

then the two open questions are:

1) Can a web app (e.g. the Addama registry) perform authorization against the Google Apps groups;

2) Can group membership be controlled programmatically.  (This is a minor need, since the Google Apps control panel allows administration of group membership.)

Notes

Q: What's the cumulative file size on the Sage SSH server?

A: About 2GB, considering the files in the directory /data/incoming on sage.fhcrc.org

Google Apps provides two APIs to help with authentication:

1. SAML Single Sign-On (SSO) Service: would allow *us* to create and maintain users and groups outside of Google.

http://code.google.com/appenginegoogleapps/docsdomain/java/users/overviewsso/saml_reference_implementation.html

4. At times like this, faced with a moral dillema, I ask myself, "What would Atlassian Do" (WWAD)?

4.1 Seraph is a very simple, pluggable J2EE web application security framework developed  by Atlassian and used in our products.

http://confluence.atlassian.com/display/DEV/Single+Sign-on+Integration+with+JIRA+and+Confluence

4.2 Crowd is a single sign-on (SSO) application for as many users, web applications
and directory servers you need — all through a single web interface.2. Google Apps Provisioning API: would allow us to programmatically create Google users and groups in our private domain.  This would streamline adding users to Google Apps.  If we used it as a total solution, then the non-google app's (e.g. Addama) would have to go to google for authentication, which violates the 'arms length' integration requirement.

3. OpenID sounds like an alternative to SAML:

http://www.atlassiangoogle.com/software/crowd/

Crowd centralises identity management, allowing you to take users from different directories
and manage them in one place. Multiple user directories can be centrally managed via Crowd's
administration console.

Crowd's OpenID authentication server, CrowdID, talks with websites and applications using
OpenID. It expands Crowd's SSO capabilities to applications outside your organisation's firewall. support/forum/p/apps-apis/thread?tid=33a3707bd2ea7904&hl=en

In the case of OpenID, the user may have a Google Account, a Google Apps Account, or an account from any other domain that provides OpenID federated login.

Integration of GAE with OpenID:

http://confluencecode.atlassiangoogle.com/displayappengine/CROWD/Configuring+the+Google+Apps+Connector
To enable single sign-on in Google Apps, you will need the Premier, Education, or Partners edition of Google Apps.
The Crowd Google Apps connector does not support the automatic adding of users. If a user exists
in Crowd but not in Google Apps, then the user will not be able to log in to Google Apps.
To add an application (e.g. a GAE app like Addama registry):docs/java/users/overview.html

4. At times like this, faced with a moral dillema, I ask myself, "What would Atlassian Do" (WWAD)?

4.1 Seraph is a very simple, pluggable J2EE web application security framework developed  by Atlassian and used in our products.

http://confluence.atlassian.com/display/CROWDDEVDEV/ApplicationSingle+Sign-on+Integration+Overview

Licensing and hosting Crowd:

- Crowd is not hosted by Atlassian.  We have to run it ourselves.  It runs on Windows, Linux or Mac and uses an apache tomcat app server:

http://confluence.atlassian.com/display/CROWD/Installing+Crowd+and+CrowdID

- Pricing:  This is a little confusing but it seems to say that it's $10 for up to 10 users then $600/$1200 for up to 100 users (academic/commercial)with+JIRA+and+Confluence

4.2 Crowd is a single sign-on (SSO) application for as many users, web applications
and directory servers you need — all through a single web interface.
http://www.atlassian.com/software/crowd/pricing.jsp

 Open source alternatives to Crowd:

Crowd centralises identity management, allowing you to take users from different directories
and manage them in one place. Multiple user directories can be centrally managed via Crowd's
administration console.

Crowd's OpenID authentication server, CrowdID, talks with websites and applications using
OpenID. It expands Crowd's SSO capabilities to applications outside your organisation's firewall.

http://codeconfluence.googleatlassian.com/googleappsdisplay/domain/open_source_projects.html#sso

- Addama authentication is via Servlet filters using GAE User Service OR a Google API-key.

- Addama services

- Sage SSH/SCP server authenticates using standard unix log-in.

- Addama handles authentication via Servlet Filters; the servlet config xml file shows what's in place.

- Addama white list: "user x can get these services, or anything under the branch."

Nicole's "an area for testing" is a "google apps for your domain" domain

 http://www.google.com/a/sagebionetworks.com is a "test domain for Google Apps"

What's the difference between a "google account" and a "google apps account"?
 A: the latter is newer and ultimately should subsume the former.

Does Google Apps support OpenID?

A: Only as an "Identity provider" (of the Google Apps ID) not as a service provider seeking authentication.

http://code.google.com/googleapps/domain/sso/openid_reference_implementation.html

3 ways to authenticate GAE
- google accounts
- google-apps account (on proprietary domain associated with Google)
- OpenID

ours is a google apps premier (="business"?) accountCROWD/Configuring+the+Google+Apps+Connector
To enable single sign-on in Google Apps, you will need the Premier, Education, or Partners edition of Google Apps.
The Crowd Google Apps connector does not support the automatic adding of users. If a user exists
in Crowd but not in Google Apps, then the user will not be able to log in to Google Apps.

To add an application (e.g. a GAE app like Addama registry):

http://confluence.atlassian.com/display/CROWDDEV/Application+Integration+Overview

Licensing and hosting Crowd:

- Crowd is not hosted by Atlassian.  We have to run it ourselves.  It runs on Windows, Linux or Mac and uses an apache tomcat app server:

http://confluence.atlassian.com/display/CROWD/Installing+Crowd+and+CrowdID

- Pricing:  This is a little confusing but it seems to say that it's $10 for up to 10 users then $600/$1200 for up to 100 users (academic/commercial)

http://www.atlassian.com/software/crowd/pricing.jsp

 Open source alternatives to Crowd:

http://code.google.com/googleapps/domain/open_source_projects.html#sso

Another alternative is "SSO Easy".

- Sage SSH/SCP server authenticates using standard unix log-in.

Addama Authentication/Authorization

- Addama authentication is via Servlet filters using GAE User Service OR a Google API-key.

- Addama handles authentication via Servlet Filters; the servlet config xml file shows what's in place.

- Addama white list: "user x can get these services, or anything under the branch."

Notes on Addama Registry Filters:

...

 org.systemsbiology.addama.coresvcs.gae.filters.ProxiesFilter
  Seems to forward certain requests (in particular, non-registry requests) to GAE's "URLFetchService".

- what does <security-constraint> in the GAE web.xml file mean?
A: from http://code.google.com/appengine/docs/java/users/overview.html
If you have pages that the user should not be able to access unless signed in, you can establish a security constraint for those pages in the deployment descriptor (the web.xml or app.yaml file). If a user accesses a URL with a security constraint and the user is not signed in, App Engine redirects the user to the sign-in page automatically (for Google Accounts or Google Apps authentication) or to the page at /_ah/login_required (for OpenID authentication), then directs the user back to the URL after signing in or registering successfully.

A security constraint can also require that the user be a registered administrator for the application. This makes it easy to build administrator-only sections of the site, without having to implement a separate authorization mechanism.

Nicole's "an area for testing" is a "google apps for your domain" domain

 http://www.google.com/a/sagebionetworks.com is a "test domain for Google Apps"

What's the difference between a "google account" and a "google apps account"?
 A: the latter is newer and ultimately should subsume the former.

Does Google Apps support OpenID?

A: Only as an "Identity provider" (of the Google Apps ID) not as a service provider seeking authentication.

http://code.google.com/googleapps/domain/sso/openid_reference_implementation.html

3 ways to authenticate GAE
- google accounts
- google-apps account (on proprietary domain associated with Google)
- OpenID

ours is a google apps premier (="business"?) account


Notes on Authorization

From:

...