COmanage Developers List

[Steven Carmody <>]

If there's time during tomorrow's conference call, Benn and I would like 
to hear people's comments and feedback on these:

1) Researcher joins CO/VO and uses resources.

-- CO manager goes to CO, logs in, creates Groups

-- CO manager associates various permissions with newly defined Groups

-- CO manager causes Shib IDP instance at CO to release appropriate 
attributes to SPs associated with the CO but outside the CO (eg the Portal)

-- researcher uses browser to access CO.

-- researcher clicks Login, is redirected to a WAYF, choose their campus 
IDP, are redirected to their campus IDP, login, are redirected back to 
the CO.

-- The campus IDP releases these attributes to the CO:
        EPPN
        CN (optional)
        Email (optional)
        others ?

-- researcher notifies CO manager, providing their EPPN value

-- CO manager adds researcher to appropriate Groups

-- researcher accesses Portal associated with CO but outside the CO instance

-- researcher clicks Login, does the Federated dance, is returned to the 
Portal

-- the Shibboleth SP in front of the portal is configured to send an 
Attribute Query to the CO, using the researcher's EPPN value as the 
identifier; the CO IDP returns Group memberships and permissions.

-- the portal completes the Login sequence, does some access control, 
personalizes.

--  the researcher clicks on a portlet, which will access a backend 
service on behalf of the user.

-- the portlet uses the UNICON supplied library to obtain a delegated 
SAML Assertion from the campus IDP, access the backend service (also 
protected by a Shibboleth SP), present the Delegated Assertion, and 
interact with the backend service.

-- the Shibboleth SP in front of the backend service would also be 
configured to send an Attribute Query to the CO, using the researcher's 
EPPN value as the identifier; the CO IDP returns Group memberships and 
permissions.

-- the backend service accepts the SAML Assertions and does some access 
control

-- ?? initially, what would we like the backend service to do? KISS 
would be a good start  ;-)

2) student use of the portal -- I'm waiting for some feedback from Duke 
before finalizing this script.

3) Once the basic demo is working, we could possibly explore extending 
the backend services to more closely approximate the GENI Clearinghouse 
and cluster components.