Hi Sam,

On 18/04/13 18:46, Sam Hartman wrote:
[...]
>      Paul>  Normally authorisation decisions are made on group-membership
>      Paul>  rather than on an individual's identity (e.g., "members of
>      Paul>  group X are allowed to read file Y").  Therefore, it is
>      Paul>  desirable that the RP receives a set of SAML assertions that
>      Paul>  includes the group membership information.
>
> That's one way to do it.

Do you mean:

	there are other ways (from group-membership) to authorise
	a request,

or

	that there are other ways to represent group-membership
	(other than SAML assertions)?

There's obviously the possibility of the RP fetching the additional 
assertions by directly querying the community server asserting 
group-membership (e.g., a direct SAML query).

I'm actually more interested if moonshot has the concept of groups (or, 
more generally, fetching assertions from multiple IdPs), rather than 
whether it's possible to support group-based authorisation "somehow" 
(i.e., in addition to moonshot).

The latter I already pretty sure is possible ;-)


[..]
>      Paul>  Has there been any thought on how a moonshot-user's login can
>      Paul>  include communication with some 3rd-party service to obtain
>      Paul>  group-membership information?
>
> Yes. lots of ways to do this.
>
> First, Moonshot's client uses the Shibboleth  SP.
> So through that you can use the SAML simple aggregation profile to
> maintain access to group information.

OK, a couple of thoughts:

When you say "SAML simple aggregation profile", do you mean Shib's 
SimpleAggregation AttributeResolver?  I couldn't find an actual profile 
called "simple aggregation".

I believe this would result in the client fetching group-membership 
information by directly querying the IdP asserting group-membership. 
This leads to a number of questions, like how would the client know 
where to fetch the group-membership information (does every client need 
to be configured?), how does the client trust the response?

Just for my own understanding: I was under the impression that the SAML 
assertions travelled from the RADIUS server to the RP as part of the 
login process.  If so, how does the client supply additional attributes 
(in this case, group-membership)?


> feeding that into NFS tends to be tricky.

It's less of a problem for us, because we are using our own 
implementation of NFS.


> When I was looking into this for a client, my recommendation was that
> they set up a RADIUS proxy that grabbed the group information from a
> community specific location while processing the Moonshot
> access-accept. It would then insert it into a semi-local LDAP instance
> where nss-sss or nss-ldap could grab it.

Ah!  So this RADIUS proxy grabs the group-membership information.

Could it do the aggregation (similar to Shib's SimpleAggregation) and 
return the combined output?

Cheers,

Paul.