There are at least two solutions to this problem
a) either the IDP sends the group and other attributes that the RP needs
(maybe it has a local mapping capability that can map from internal
attributes to externally needed ones, per RP), or
b) the RP has an attribute mapping capability that allows it to map an
input set of IDP asserted attributes into a local set of authz
attributes, or
c) both are implemented.
Shibboleth implements the former, by sending eudPerson attributes to
SPs. We have implemented the latter in OpenStack for our cloud solution
regards
David
On 18/04/2013 13:42, Paul Millar wrote:
> Hi all,
>
> I'm thinking how moonshot may be used for a non-SSH service,
> specifically for accessing data. At the moment, I'm not sure which
> protocol(s) this will be, but let's use NFS v4 as a concrete example
> (where necessary) as Daniel has already demonstrated this with a
> Kerberos-like credential and the Linux client and server implementations.
>
> I have three distinct questions, which I'll split over three emails.
>
> Here's the first one: group member assertions
>
> Once a moonshot-user's identity is establish, information about this
> user is passed from IdP to RP as a set of SAML assertions. This is part
> of the login process.
>
> Normally authorisation decisions are made on group-membership rather
> than on an individual's identity (e.g., "members of group X are allowed
> to read file Y"). Therefore, it is desirable that the RP receives a set
> of SAML assertions that includes the group membership information.
>
> As far as I understand it, there is some support in moonshot to include
> group-membership. This comes from a moonshot-specific component (a
> "community service"?).
>
> Maintaining group membership should be done in one place and many
> communities already have existing solutions (LDAP, Grouper, VOMS
> servers, ...).
>
> Has there been any thought on how a moonshot-user's login can include
> communication with some 3rd-party service to obtain group-membership
> information?
>
> Cheers,
>
> Paul.
|