InCommonUABgrid: Difference between revisions

From Cheaha
Jump to navigation Jump to search
(Reconstruct from RSS feed.)
 
m (→‎User Notification in Case of Compromise: Fix typo: alter => alert)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
-----Original Message-----
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 [http://www.incommonfederation.org/docs/policies/incommonpop.html INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES].
From: John-Paul Robinson
 
Sent: Wednesday, March 21, 2007 3:58 PM
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.
To: David L Shealy
 
Subject: incommon resource provider
__TOC__
 
Here's a first draft at the resource provider application for InCommon.
== Resource Provider Information ==
Let me know what you think. We should involve Puri and Alan after we
<blockquote>
get the foundation in place so they can comment on the requirements they
Resource Providers are trusted to ask for only the information necessary
envision to enable access to their resources.
to make an appropriate access control decision, and to not misuse
information provided to them by Credential Providers. Resource
  I'm trying to be honest and general in my description. It's important
Providers must describe the basis on which access to resources is
to remember that InCommon requires that we document our operating
managed and their practices with respect to attribute information they
practices so that they can be reviewed by members of InCommon. It does
receive from other Participants.
not require any specific level of security, leaving that to the
</blockquote>
discretion of peers who decide to trust the application. I think its
 
important to document what we see as our initial goals, acknowledging
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.
the fact that these operating policies will likely change over time as
 
experience is gained collaborating with UABgrid. There is little
UABgrid's planned resource provider id will be:
precedent for this type of service, so part of our effort is determining
 
appropriate and acceptable operating procedures.
:<nowiki>https://uabgrid.uab.edu/shibboleth</nowiki>
 
~jpr
=== Required Attributes ===
<blockquote>
>From section 3 of the "INCOMMON FEDERATION: PARTICIPANT OPERATIONAL
3.1 What attribute information about an individual do you require
PRACTICES"
in order to manage access to resources you might make available to other
(http://www.incommonfederation.org/docs/policies/incommonpop.html)
Participants? Describe separately for each resource ProviderID that you
have registered.
3 Resource Provider Information
</blockquote>
 
Resource Providers are trusted to ask for only the information necessary
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
to make an appropriate access control decision, and to not misuse
their Identity Provider. An identity provider may supply a targeted id in addition to or in lieu of ePPN.
information provided to them by Credential Providers. Resource
 
Providers must describe the basis on which access to resources is
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.
managed and their practices with respect to attribute information they
 
receive from other Participants.
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.
UABgrid is a collaboration environment for use by UAB community members
 
and their designated collaborators from UAB and from other campuses to
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
organize around shared academic interests. UABgrid is a participant
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.
directed and controlled collaboration environment that will provide
 
access to web and grid applications. Basic access will be broadly
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
available with additional privileges granted to specific community
and phone number of a user, only that application will receive this additional information.
members based on the information provided by credential providers and
 
peers within the community.
=== How Attributes are Used ===
<blockquote>
UABgrid's planned resource provider id will be:
3.2 What use do you make of attribute information that you receive
in addition to basic access control decisions? For example, do you
https://uabgrid.uab.edu/shibboleth
aggregate session access records or records of specific information
accessed based on attribute information, or make attribute information
3.1 What attribute information about an individual do you require
available to partner organizations, etc.?
in order to manage access to resources you might make available to other
</blockquote>
Participants? Describe separately for each resource ProviderID that you
 
have registered.
The ePPN will be used to identify an individual user within UABgrid both
to web applications and grid resources. This will essentially by their
The only required attribute required to access basic UABgrid resources
"user identity" within the system.
will be eduPersonPrincipleName (ePPN). This attribute is intended to
 
provide a unique identity for each user that reflects their identity at
The email address will enable the user to participate in provided email-
their Identity Provider. An identity provider may supply a targeted id
based discussions related to the groups with which they participate.
in addition to or in lieu of ePPN, however, no access will be granted
The email address will also be used to communicate system-wide
with out either of these identity attributes.
announcements to the user and may be used by application providers to
communicate with the user. Essentially, the email address considered a
An identity provider may supply an email attribute along with the ePPN
communication end point for the user of the UABgrid system environment.
or targeted id. If supplied, this address should be considered a
 
working email address. This attribute will be used to pre-populate
Additional attributes that may be required for authorizations beyond
application forms as a convenience to the end user. However, a user
basic access will be used to help identify the individual to resource
will be allowed to override the supplied email address and supplied an
providers so that authorization requests can be reviewed.
alternative working email address, verified during registration.
 
=== Personally Identifying Attributes Access Controls ===
Please note: UABgrid will not consider the ePPN, targeted id or email
<blockquote>
address to constitute personally identifiable information. Users and
3.3 What human and technical controls are in place on access to and
identity providers concerned with privacy at the user-account level are
use of attribute information that might refer to only one specific
asked to supply opaque identifiers (such as targeted id) whose mapping
person, i.e. personally identifiable information? For example, is this
to personally identified information is maintained by the identity
information encrypted?
provider at the identity provider.
</blockquote>
 
While this information will be sufficient for basic participation in
Access to the databases that store personally identifiable information
UABgrid, access to specific resources may require additional information
will be controlled via standard system security procedures. Only UABgrid
either asserted by the users identity provider or by authorized peers
operators will have access to centrally stored attributes. Attributes
on UABgrid. An example of these attributes may include the users common
made available to specific resource providers will be under the control
name and affiliation as asserted by the identity provider in order to
of those resource providers. User discretion is advised.
access a computational resource. Requests for these attributes will be
 
identified and determined by resource providers on UABgrid. Users
=== Privileged Account Access Controls ===
should have the ability to control the release of these additional
<blockquote>
attributes, with the understanding that denying their release may
3.4 Describe the human and technical controls that are in place on
restrict their levels of privilege on UABgrid.
the management of super-user and other privileged accounts that might
have the authority to grant access to personally identifiable information?
When requested, every effort will be made to make these additional
</blockquote>
attributes available only to the applications that require them. For
 
example, if a grid compute resource provider requires the common name
Privileged accounts will be restricted to a limited set of experienced
and phone number of a user, only that application will receive this
UABgrid operators. These operators will be familiar with standard
additional information.
security practices regarding the management of personal information.
 
3.2 What use do you make of attribute information that you receive
=== User Notification in Case of Compromise ===
in addition to basic access control decisions? For example, do you
<blockquote>
aggregate session access records or records of specific information
3.5 If personally identifiable information is compromised, what
accessed based on attribute information, or make attribute information
actions do you take to notify potentially affected individuals?
available to partner organizations, etc.?
</blockquote>
 
The ePPN will be used to identify an individual user within UABgrid both
In this event UABgrid will make a reasonable effort to contact the user
to web applications and grid resources. This will essentially by their
via email to notify them of the event. Additionally, UABgrid will alert
"user identity" within the system.
the user's identity provider to the compromise.
 
The email address will enable the user to participate in provided email-
Please note, UABgrid is a pilot service. Every effort will be made to
based discussions related to the groups with which they participate.
protect provided information. Users are encourage to exercise
The email address will also be used to communicate system-wide
discretion and evaluate requests for information based on their trust of
announcements to the user and may be used by application providers to
the services provided. At the point UABgrid becomes a non-pilot service
communicate with the user. Essentially, the email address considered a
additional operating practices and procedures may come into effect which
communication end point for the user of the UABgrid system environment.
may augment or replace those described here.
 
Additional attributes that may be required for authorizations beyond
== Other Information ==
basic access will be used to help identify the individual to resource
=== Shibboleth Version ===
providers so that authorization requests can be reviewed.
<blockquote>
4.1      Technical Standards, Versions and Interoperability
3.3 What human and technical controls are in place on access to and
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.
use of attribute information that might refer to only one specific
</blockquote>
person, i.e. personally identifiable information? For example, is this
 
information encrypted?
The UABgrid SP runs Shibboleth version 1.3 code.
 
Access to the databases that store personally identifiable information
=== Other Considerations ===
will be controlled via standard system security procedures. Only UABgrid
<blockquote> 
operators will have access to centrally stored attributes. Attributes
4.2      Other Considerations
made available to specific resource providers will be under the control
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?
of those resource providers. User discretion is advised.
</blockquote> 
 
3.4 Describe the human and technical controls that are in place on
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.
the management of super-user and other privileged accounts that might
 
  have the authority to grant access to personally identifiable information?
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.
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.
  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 alter
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.

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.