>>>>> "Paul" == Paul Millar <[log in to unmask]> writes:
Paul> Once a moonshot-user's identity is establish, information
Paul> about this user is passed from IdP to RP as a set of SAML
Paul> assertions. This is part of the login process.
That's one way to do it.
You can also pass RADIUS attributes. Either works fine.
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.
Paul> As far as I understand it, there is some support in moonshot
Paul> to include group-membership. This comes from a
Paul> moonshot-specific component (a "community service"?).
Not currently.
There are discussions in Janet's deployment of moonshot as a future work
item to make it easy to maintain these SAML assertions in one place for
a given community.
Paul> Maintaining group membership should be done in one place and
Paul> many communities already have existing solutions (LDAP,
Paul> Grouper, VOMS servers, ...).
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.
feeding that into NFS tends to be tricky.
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.
I'm happy to answer general questions here. Also, obviously Painless
Security would be delighted to work with a client on this sort of
project.
--Sam
|