COmanage Developers List

[Scott Koranda <>]

> 
> 
> ----- Original Message -----
> > From: "Scott Koranda" 
> > <>
> > To: "heather flanagan" 
> > <>
> > Cc: "CoMaNaGe-DeV List" 
> > <>
> > Sent: Thursday, September 29, 2011 1:53:21 PM
> > Subject: Re: [comanage-dev] Fwd: paccman working group
> > 
> > Hi,
> > 
> > >    Hi folks -
> > > 
> > >    Scott and Marie in particular, do you have any specific requests
> > >    for me to
> > >    bring to the paccman wg next week?
> > 
> > Would we have time to chat about this on Monday?
> > 
> > I don't have a good idea of what the paccman working group
> > does or how they might help, so it is difficult for me to
> > brainstorm on what they might help with.
> > 
> > Thanks,
> > 
> 
> Probably not, since the paccman working group session is an
> early morning one.  And don't worry too much about having a
> good idea about what the paccman working group does, 'cause
> they don't actually know either.  They're looking for
> direction.  I'm going to aim them at best practices in the
> account linking + authorization space.
> 

Ah. This actually helps a lot. I can give you a VO use case
for account linking + authorization (At least I think it is a good use
case...).

So as you know from the Milwaukee meeting we have the green
light to federate. On Friday we spent time actually going
through more SPs and we found that there is a good mixture of
SPs for which we will only require Bronze (or no IAP) and
others that will require Silver.

But we also realized that some SPs run the entire spectrum and
that the assurance required is not so much tied to the SP but
to the authorization. Let me explain...

The LIGO Document Control Center or DCC is a good example. It
is the place where all LIGO documents are to be stored and
catalogued. Some of the documents are very low risk (some are
even public) and coming in with a federated identity with
little assurance (not even Bronze) is fine. 

Some of the documents are higher risk and accessing them with
a federated identity is going to require a Silver
assurance--we need to be sure we understand who is accessing
those documents. So we are going to authorize access to those
documents not only to the identity, but also require that the
identity is being asserted with Silver.

So before the ACL might have been 


 is in group Communities:LVC:LSC:ExecutiveCommittee

but now the ACL will have to be


 is in group Communities:LVC:LSC:ExecutiveCommitee AND the IdP is asserting 
Silver

Still, there are some documents that we consider super
sensitive--access by the wrong people could lead to real legal
problems costing real money, or major embarrassment to the
project or people in the project.

For those documents we are going to require the use of a LIGO
credential (until such time there is a 'Gold' level of
assurance from InCommon that we can embrace). So the ACL will
still be


 is in group Communities:LVC:LSC:ExecutiveCommittee

That means that in order to support federation for this SP and
have a good user experience, we need 


 and 


to be linked and linked well, and to have the authorization
work well.

Ideally Patrick can browse around on a daily basis using
,
 but when the DCC doesn't want to let him see
a document because only 

 can see it,
ideally the DCC itself as an application can somehow get
enough help from the infrastructure to say "Did you perhaps
want to use your 

 identity instead?" and
then when he clicks "yes" the appropriate assertions happen
and it all "just works".

In order for that to be seamless and work well I think there
has to be an easy way for an application to "hook into" some
infrastructure so that when an authorization is denied it can
see if there is a linked profile that would have been given
access and then provide a flow that works for the user.

Or maybe the application is just configured that whenever it
denies some authorization the flow sends the browser to some
service and the service does the hard work? 

I don't know...but perhaps the working group can come up with
the right idea.

Hope this helps,

Scott