As a user, I want to authorize a new third-party application

[afeld]

For example, I'm interested in publishing an Ansible Role (plugin) to Ansible Galaxy, but this requires allowing access to the GSA GitHub organization. Basically, what would be required before we click this button?

@jerodweaver @boberlas Thoughts?

[afeld]

Ha, now remembering that I wrote up a proposal around this a while ago for 18F. Any interest in ratifying that for GSA? Comments welcome!

[JJediny]

@afeld while this is scoped to OAuth permissions for 3rd party services from Google Accounts, it would seem appropriate to extend this same logic to Github.

See Figure 2 - Allowed OAuth 2.0 Access Scopes if extended to Github this policy would support approval per the Ansible Galaxy example. I.e. Read-only authorizations to basic or otherwise pubic user/org info

CIO IL-16-01 Policy for OAuth 2.0 Integration with GSA.gov Accounts

GENERAL SERVICES ADMINISTRATION CIO IL-16-01 July 26, 2016

GSA INSTRUCTIONAL LETTER

SUBJECT: Policy for OAuth 2.0 Integration with GSA.gov Accounts

1. Purpose. This Instructional Letter (IL) establishes GSA policies for OAuth 2.0 integration of GSA.gov accounts with third party services including but not limited to Websites, Software as a Service (SaaS), mobile applications, and Google Apps Scripts.

2. Applicability. The provisions of this IL apply to all GSA employees and contractors. This IL applies to the Office of Inspector General (OIG) only to the extent that the OIG determines that the Order is consistent with the OIG’s independent authority under the IG Act and it does not conflict with other OIG policies or the OIG mission.

3. Policy. OAuth 2.0 is an industry standard protocol approved by GSA. It enables a GSA.gov user to grant access to their account or data in Google Apps to a relying party. It is used in a wide variety of services for user authentication.

   a. GSA IT’s Office of the Chief Information Security Office (OCISO) shall monitor and restrict the integration of GSA.gov accounts with OAuth 2.0 to third party services including but not limited to Websites, Software as a Service (SaaS), mobile applications, and Google Apps Scripts.

   b. OAuth 2.0 Access Scopes are used to limit the authorization granted to the relying service by the GSA.gov user. The Access Scopes in Figure 1 present risk to GSA.gov accounts and data and are prohibited unless integrated with websites, mobile apps, and SaaS Authorized to Operate by GSA and/or included in the GSA IT Standards Profile.

Figure 1. Restricted OAuth 2.0 Access Scopes to GSA.gov Accounts

Access Scope	Description
Access Inbox and Contacts Information	Allows view of email messages and settings
Access Personal Information	Allows Manage of user calendars
Act on Behalf of User	Allows View and modify but not delete user email
Full Data Access	Allows view and manage of files and documents in connecting users Google Drive
Limited Access to Data and Files	Can be varied from access to a single file to allowing the app to View and manage its own configuration data in your Google Drive
Manage Devices	Administrator's scope to view and manage your mobile devices' metadata
Manage User Activity	Administrator's scope to view users on your domain; manage org units in domain; view org units in domain; view and manage provisioning of users in domain; general domain API operations include managing a domain's language, organization name, max number of users; current number of users
Other	Misc. permissions
Payment Information	Read Google Wallet credentials from the production environment.
Read Only Access To Data and Files	Read Only Access To Data and Files
Access Location Information	Google Map Data API - View your Google Maps Engine Data; Google FIT: Location

c. The OAuth 2.0 Access Scopes defined in Figure 2 are authorized for integration with GSA.gov accounts with no restriction.

Figure 2. Allowed OAuth 2.0 Access Scopes

Access Scope	Description
Basic Info	View your email address; View basic information about your account, including name, public profile URL, photo, gender, birthdate, country, language, and time zone
Limited Access to Data and Files	Access Google+ features which are generally public.

d. Google Apps Script is a JavaScript cloud scripting language that facilitates the automation of routine tasks across Google Apps and third party services. All scripts are subject to GSA IT review to verify author; access scope; where the script resides (e.g., internal vs external); type of data accessed; and storage of accessed data.

(1) Internally developed scripts are implicitly allowed but may be restricted pending results of the OCISO review.

(2) Internally developed scripts shall follow GSA naming conventions – GSA_ 2 Letter Service/Staff Office Designation_Script Name (e.g., GSA_IS_Script Name).

(3) Externally developed scripts are prohibited but may be allowed following OCISO review and approval.

(4) OCISO shall develop a process to review and approve Google Apps Scripts (internal and external) within 30 days of the signing of this IL.

e. GSA IT shall provide training on safely accessing third party services with GSA.gov accounts and OAuth 2.0.

[jerodweaver]

@afeld I would have to defer to Bo or Man on this one, but, in my opinion based on the facts presented, I would say it wouldn't be allowed. Looking at the info John posted, and assuming your "Org and Team Membership" information is NOT public, I would actually say the request to read "Org and Team Membership" falls into "Read Only Access to Data and Files", in Figure 1 (which is restricted).

[afeld]

Note: my ask in this issue is not so much about Ansible Galaxy specifically, but using that as an example.

"Org and Team Membership" information is NOT public

While not always public - the organization member or team creator (respectively) needs to opt-in to make it so - that information is not sensitive.

A while ago, I put together a list of scopes that are read-only and non-sensitive here. I believe @boberlas agreed to them at the time - @boberlas, do you remember? Anyway, my proposal is:

Any integration requesting a subset of those "basic scopes" be approved for @GSA without further review. Anything application requesting scopes beyond those gets routed through the IT Standards process.

We can create a Google Form or whatever makes the most sense to collect the initial information. Sound reasonable?