Hi Matthew

On 08/04/2014 18:21, Matthew Vernon wrote:
> Hi,
>
> I have some questions about where moonshot is going regarding some
> technical aspects of identity and access management. Perhaps this is all
> stuff that's in the works...
>
> With Shibboleth, there's quite a bit of flexibility at both the IdP and
> SP ends in terms of anonymous / pseudonymous / nonymous logins.

But of course none of this is available to or seen by the end user in
current Shibboleth implementations. Users have no knowledge about any of
their identity attributes that are sent from the IdP to the SP.

So there are two separate issues here:
i) how can the SP get the attributes it needs for authz purposes
ii) how can the user have some consent and control over this.

I see no reason why Moonshot cannot be just as flexible as Shibboleth in
the first case. The SP can ask for the attributes that it wants from the
IdP in either the Radius request or subsequently in a SAML request, and
the IdP can make decisions about what to release in just the same way
that it does now in Shibboleth.

I think that ii) will be more difficult to engineer in Moonshot since a
browser is not involved and it will be more difficult for the IdP to
enter into a dialogue with the user about which of his/her attributes
should be released. Note that whilst Shibboleth implementations
generally do not do this today, there is nothing in principle stopping
them from doing this, and if you login via Google you will see that
Google is already doing this via the OpenID login protocol.

regards

David

So the
> IdP can make sophisticated decisions about which attributes to release
> to which SPs, and SPs can in turn make decisions about access control
> based on which attributes are asserted by SPs.
>
> I can envisage lots of analogous use cases for Moonshot, and I've not
> yet seen much to suggest how much of this will be possible now/by the
> end of the pilot/"at some point". For example, considering
> moonshot-enhanced ssh:
>
> IdPs might want to only provide pseudonyms to remote ssh servers;
> possibly users might want to be able to say "I want to log onto the
> remote server, but only if I can do so thus" e.g. with something like
> eduPersonPersistentID
>
> My ssh server might want logic like some of the following:
>
> a) create accounts for anyone at Oxford
> b) create a temporary guest account for pseudonymous users, but throw it
> away later
> c) for /any/ unknown user, refuse login, log the request, and let an
> admin decide to approve the user infuture
> d) create temporary accounts for anyone in the federation, and let an
> admin decide whether to upgrade particular accounts to full accounts
>
> These sorts of features would be really useful, but I'm not sure when/if
> moonshot will be supporting them, and how much of this sort of behaviour
> is going to be standardised?
>
> Regards,
>
> Matthew
>