InCommonUABgrid: Difference between revisions

From Cheaha
Jump to navigation Jump to search
(→‎Required Attributes: Remove missleading access restriction.)
m (→‎User Notification in Case of Compromise: Fix typo: alter => alert)
 
(4 intermediate revisions by 2 users not shown)
Line 38: Line 38:


While this information will be sufficient for basic participation in UABgrid, access to specific resources may require additional information either asserted by the user's identity provider or by authorized peers
While this information will be sufficient for basic participation in UABgrid, access to specific resources may require additional information either asserted by the user's identity provider or by authorized peers
on UABgrid. An example of these attributes may include the userss common name and affiliation as asserted by the identity provider in order to access a computational resource. Requests for these attributes will be identified and determined by resource providers on UABgrid. Users should have the ability to control the release of these additional attributes, with the understanding that denying their release may restrict their levels of privilege on UABgrid.
on UABgrid. An example of these attributes may include the users common name and affiliation as asserted by the identity provider in order to access a computational resource. Requests for these attributes will be identified and determined by resource providers on UABgrid. Users should have the ability to control the release of these additional attributes, with the understanding that denying their release may restrict their levels of privilege on UABgrid.


When requested, every effort will be made to make these additional attributes available only to the applications that require them. For example, if a grid compute resource provider requires the common name
When requested, every effort will be made to make these additional attributes available only to the applications that require them. For example, if a grid compute resource provider requires the common name
Line 99: Line 99:


In this event UABgrid will make a reasonable effort to contact the user
In this event UABgrid will make a reasonable effort to contact the user
via email to notify them of the event. Additionally, UABgrid will alter
via email to notify them of the event. Additionally, UABgrid will alert
the user's identity provider to the compromise.
the user's identity provider to the compromise.


Line 108: Line 108:
additional operating practices and procedures may come into effect which
additional operating practices and procedures may come into effect which
may augment or replace those described here.
may augment or replace those described here.
== Other Information ==
=== Shibboleth Version ===
<blockquote>
4.1      Technical Standards, Versions and Interoperability
Identify the version of Internet2 Shibboleth code release that you are using or, if not using the standard Shibboleth code, what version(s) of the SAML and SOAP and any other relevant standards you have implemented for this purpose.
</blockquote>
The UABgrid SP runs Shibboleth version 1.3 code.
=== Other Considerations ===
<blockquote> 
4.2      Other Considerations
Are there any other considerations or information that you wish to make known to other Federation participants with whom you might interoperate, e.g., concern about the use of clear text passwords or responsibilities in case of a security breach involving identity information you may have provided?
</blockquote> 
In addition to the above policy outlines, UABgrid is governed by UAB information technology policies.  You can read more about these policies on the [http://www.uab.edu/it/policies/index.html UAB IT Policies and Guidelines] page. These policies govern resources located at UAB such as the UABgrid infrastructure and other on-campus applications.  Because UABgrid supports the inclusion of VO applications not located on campus, other policies may govern such off-campus resources. These policies are under the control of the respective resource owners and any agreement between UABgrid and the respective resource provider determined during the course of adding that resource to the UABgrid.  It is the intention to provide access to these policies for public review.
Over time, the above point-by-point responses specific to InCommon will be incorporated into an overally privacy and policy document for UABgrid.  Please check back with this page for updates.

Latest revision as of 14:34, 25 September 2007

To register UABgrid as a resource provider for InCommon we need define the UABgrid operational practices by addressing the "Resource Provider Information" questions from section 3 of the INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES.

The questions from section 3 and proposed answers are listed below. We will likely also want to our final document to be more of an operating practices document than a list of questions and responses.

Resource Provider Information

Resource Providers are trusted to ask for only the information necessary to make an appropriate access control decision, and to not misuse information provided to them by Credential Providers. Resource Providers must describe the basis on which access to resources is managed and their practices with respect to attribute information they receive from other Participants.

UABgrid is a collaboration environment for use by UAB community members and their designated collaborators from UAB and from other campuses to organize around shared academic interests. UABgrid is a participant directed and controlled collaboration environment that will provide access to web and grid applications. Basic access will be broadly available with additional privileges granted to specific community members based on the information provided by credential providers and peers within the community.

UABgrid's planned resource provider id will be:

https://uabgrid.uab.edu/shibboleth

Required Attributes

3.1 What attribute information about an individual do you require in order to manage access to resources you might make available to other Participants? Describe separately for each resource ProviderID that you have registered.

The only attribute required for basic access to UABgrid resources will be eduPersonPrincipleName (ePPN). This attribute is intended to provide a unique identity for each user that reflects their identity at their Identity Provider. An identity provider may supply a targeted id in addition to or in lieu of ePPN.

An identity provider may supply an email attribute along with the ePPN or targeted id. If supplied, this address should be considered a working email address. This attribute will be used to pre-populate application forms as a convenience to the end user. However, a user will be allowed to override the supplied email address and supplied an alternative working email address, verified during registration.

Please note: UABgrid will not consider the ePPN, targeted id or email address to constitute personally identifiable information. Users and identity providers concerned with privacy at the user-account level are asked to supply opaque identifiers (such as targeted id) whose mapping to personally identified information is maintained by the identity provider at the identity provider.

While this information will be sufficient for basic participation in UABgrid, access to specific resources may require additional information either asserted by the user's identity provider or by authorized peers on UABgrid. An example of these attributes may include the users common name and affiliation as asserted by the identity provider in order to access a computational resource. Requests for these attributes will be identified and determined by resource providers on UABgrid. Users should have the ability to control the release of these additional attributes, with the understanding that denying their release may restrict their levels of privilege on UABgrid.

When requested, every effort will be made to make these additional attributes available only to the applications that require them. For example, if a grid compute resource provider requires the common name and phone number of a user, only that application will receive this additional information.

How Attributes are Used

3.2 What use do you make of attribute information that you receive in addition to basic access control decisions? For example, do you aggregate session access records or records of specific information accessed based on attribute information, or make attribute information available to partner organizations, etc.?

The ePPN will be used to identify an individual user within UABgrid both to web applications and grid resources. This will essentially by their "user identity" within the system.

The email address will enable the user to participate in provided email- based discussions related to the groups with which they participate. The email address will also be used to communicate system-wide announcements to the user and may be used by application providers to communicate with the user. Essentially, the email address considered a communication end point for the user of the UABgrid system environment.

Additional attributes that may be required for authorizations beyond basic access will be used to help identify the individual to resource providers so that authorization requests can be reviewed.

Personally Identifying Attributes Access Controls

3.3 What human and technical controls are in place on access to and use of attribute information that might refer to only one specific person, i.e. personally identifiable information? For example, is this information encrypted?

Access to the databases that store personally identifiable information will be controlled via standard system security procedures. Only UABgrid operators will have access to centrally stored attributes. Attributes made available to specific resource providers will be under the control of those resource providers. User discretion is advised.

Privileged Account Access Controls

3.4 Describe the human and technical controls that are in place on the management of super-user and other privileged accounts that might have the authority to grant access to personally identifiable information?

Privileged accounts will be restricted to a limited set of experienced UABgrid operators. These operators will be familiar with standard security practices regarding the management of personal information.

User Notification in Case of Compromise

3.5 If personally identifiable information is compromised, what actions do you take to notify potentially affected individuals?

In this event UABgrid will make a reasonable effort to contact the user via email to notify them of the event. Additionally, UABgrid will alert the user's identity provider to the compromise.

Please note, UABgrid is a pilot service. Every effort will be made to protect provided information. Users are encourage to exercise discretion and evaluate requests for information based on their trust of the services provided. At the point UABgrid becomes a non-pilot service additional operating practices and procedures may come into effect which may augment or replace those described here.

Other Information

Shibboleth Version

4.1 Technical Standards, Versions and Interoperability Identify the version of Internet2 Shibboleth code release that you are using or, if not using the standard Shibboleth code, what version(s) of the SAML and SOAP and any other relevant standards you have implemented for this purpose.

The UABgrid SP runs Shibboleth version 1.3 code.

Other Considerations

4.2 Other Considerations Are there any other considerations or information that you wish to make known to other Federation participants with whom you might interoperate, e.g., concern about the use of clear text passwords or responsibilities in case of a security breach involving identity information you may have provided?

In addition to the above policy outlines, UABgrid is governed by UAB information technology policies. You can read more about these policies on the UAB IT Policies and Guidelines page. These policies govern resources located at UAB such as the UABgrid infrastructure and other on-campus applications. Because UABgrid supports the inclusion of VO applications not located on campus, other policies may govern such off-campus resources. These policies are under the control of the respective resource owners and any agreement between UABgrid and the respective resource provider determined during the course of adding that resource to the UABgrid. It is the intention to provide access to these policies for public review.

Over time, the above point-by-point responses specific to InCommon will be incorporated into an overally privacy and policy document for UABgrid. Please check back with this page for updates.