InCommonUABgrid

From Cheaha
Revision as of 02:45, 1 July 2007 by Jpr@uab.edu (talk | contribs) (Reconstruct from RSS feed.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Attention: Research Computing Documentation has Moved
https://docs.rc.uab.edu/


Please use the new documentation url https://docs.rc.uab.edu/ for all Research Computing documentation needs.


As a result of this move, we have deprecated use of this wiki for documentation. We are providing read-only access to the content to facilitate migration of bookmarks and to serve as an historical record. All content updates should be made at the new documentation site. The original wiki will not receive further updates.

Thank you,

The Research Computing Team


Original Message-----

From: John-Paul Robinson 
Sent: Wednesday, March 21, 2007 3:58 PM
To: David L Shealy
Subject: incommon resource provider

Here's a first draft at the resource provider application for InCommon.
Let me know what you think. We should involve Puri and Alan after we
get the foundation in place so they can comment on the requirements they
envision to enable access to their resources.

I'm trying to be honest and general in my description. It's important
to remember that InCommon requires that we document our operating
practices so that they can be reviewed by members of InCommon. It does
not require any specific level of security, leaving that to the
discretion of peers who decide to trust the application. I think its
important to document what we see as our initial goals, acknowledging
the fact that these operating policies will likely change over time as
experience is gained collaborating with UABgrid. There is little
precedent for this type of service, so part of our effort is determining
appropriate and acceptable operating procedures.

~jpr

>From section 3 of the "INCOMMON FEDERATION: PARTICIPANT OPERATIONAL
PRACTICES"
(http://www.incommonfederation.org/docs/policies/incommonpop.html)

3 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

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 required attribute required to access basic 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, however, no access will be granted
with out either of these identity attributes.

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 users 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.

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.

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.

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.

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.