Currently, you map a Moonshot identity to a POSIX user, then the operating system (through NSS, and thus files/LDAP/etc) is responsible for mapping that username to a token (UID and set of GIDs). On Windows, it's a similar story, except the Moonshot identity is mapped to a Windows user through the registry or Active Directory.

Mapping individual claims to groups is an interesting idea, particularly given that the APIs make all attributes available to the application. (There is actually some support in the SSP for this: any values of the GroupSidClaim attribute will be used to create a restricted token.)

We could do it on POSIX, but then there's the question of who has the authority to issue them, given the lack of a hierarchical namespace for UIDs/GIDs. (Federating a flat namespace is a harder problem, particularly if you have an existing deployment. It can be done, of course. Many applications require that UIDs/GIDs be able to be mapped to names, so you'd need to define a protocol for that.)

And you would still have to modify applications because, unlike Windows, they don't expect to get their POSIX authorisation information from a GSS-API or SASL context. If you'd solved this problem then yes, I agree, it would be useful to have either the local Shibboleth resolver or the RP's local AAA server be able to map arbitrary SAML attributes to UIDs/GIDs that are valid in the RP's administrative domain. This certainly provides for more dynamic authorisation than a static mapping in a directory service.

The other approach is to add support for claims directly to the kernel (tokens and ACLs). Windows 8 does this, although the Moonshot SSP doesn't yet take advantage of this. It would be possible, though, but even then it's probably a long time before something equivalent happens the Unix world.

I hope this mail actually addressed your question and/or isn't too discouraging.

-- Luke

On 18/04/2013, at 8:42 AM, Paul Millar <[log in to unmask]> 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.

--
Luke Howard / [log in to unmask]
www.padl.com / www.lukehoward.com