can a service provider validate an authorization delegation?

[Robert Duncan]

Thanks Scott,

I only ask because I'm subscribed to a bug in OpenStack detailing this scenario, now it looks like this type of delegated authorization is causing concerns/issues.
https://bugs.launchpad.net/keystone/+bug/1600366

OpenStack administrators won't always control the SP I suppose - but possibly some sort of conditional check could be baked in to keystone
https://wiki.openstack.org/wiki/Keystone

Perhaps if you had the time you could chime in with some thoughts - I think someone with your level of insight into federated AuthN would be extremely useful, I am not a contributor but would like for it to work.

Thanks,
Rob.

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday 1 February 2017 16:54
To: Shib Users <users at shibboleth.net>
Subject: Re: can a service provider validate an authorization delegation?

On 2/1/17, 11:35 AM, "users on behalf of Robert Duncan" <users-bounces at shibboleth.net on behalf of Robert.Duncan at ncirl.ie> wrote:

> e.g. user A delegates a role to user B - is there any method by which
> to check if user A is still a member of the organization?

The only feature that pertains to an SP asking arbitrary questions about an arbitrary subject is the attribute query, which most IdPs increasingly don't support and wouldn't support in the manner you mean anyway. There are some federations with smallish membership and more control that rely on queries together with persistent identifiers of whatever sorts to do liveness checks. It happens, but it's not a widespread thing.

> If the application has a read only view of ldap this is possible by
> checking if the account is enabled/exists - is there any similar way of asking ECP the same question.

Not without profiling specific methods that you could never rely on unless you control all the players, just like in the LDAP case. You can always take an enterprise scenario and implement it with just about any technology.

> - cloud application such as AWS and OpenStack often use
> trustor/trustee model of delegation, the trustee can be a service
> account that acts on behalf of the user (e.g. scale up) - so is there any known way of placing a condition on this type of authorization while using SAML.

The IdP has been the vehicle for that condition. I get what you're asking, and I guess the answer is that as much as it would be nice to get the IdP off the hook from actually regulating the delegation, I don't think it really works outside the firewall.

Possibly there would be a big push to profile and adopt a basic mechanism for this if there were real extant adoption of federated authorization models, but to be honest, you just named AWS, literally the only application I have encountered in 17 years of working on this that actually requires, or even accepts the idea of, federated authorization. And that's stil a single IdP play. Which I guess answers your question: AWS doesn't implement it, but if you were the SP and you operated the IdP, yes, you can set up use of queries for this. SWITCH has examples of this in our wiki somewhere I believe, or at least elsewhere on the web.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
________________________________

The information contained and transmitted in this e-mail is confidential information, and is intended only for the named recipient to which it is addressed. The content of this e-mail may not have been sent with the authority of National College of Ireland. Any views or opinions presented are solely those of the author and do not necessarily represent those of National College of Ireland. If the reader of this message is not the named recipient or a person responsible for delivering it to the named recipient, you are notified that the review, dissemination, distribution, transmission, printing or copying, forwarding, or any other use of this message or any part of it, including any attachments, is strictly prohibited. If you have received this communication in error, please delete the e-mail and destroy all record of this communication. Thank you for your assistance.
________________________________