Protocol extensions discussion -Shib or SAML first?

[Cantor, Scott]

On 10/31/15, 6:55 AM, "users on behalf of Phil Lello" <users-bounces at shibboleth.net on behalf of phil at dunlop-lello.uk> wrote:



>I've got a use case for a SAML extension for Shibboleth, and wondered if it is better discussing here or on the SAML list first, given that my default implementation would be Shibboleth.

I don't know if you're asking us to do something or if you're suggesting that you plan to do something and wanted to know where you should do it.

We don't, generally speaking, host specs. We have a few minor extensions to metadata, but we don't in general implement things that aren't specified somewhere else.

But if we're not doing the work, then it's obviously not for us to say.

>I've been nibbling around the edges of integrating federated identities with SSH. My thought process to date is that this should be handled by teaching SSH to handle SAML, however it occurs to me that as long as the SSH server has a mechanism to perform an authorisation check for an identifiy/key combination, this can be tackled as a server-side issue, hopefully resulting in wider implementation sooner.

I would argue you don't need anything in that case. Just provision the keys. If you use a web-based mechanism to associate the keys with identifies, you don't need to touch SSH at all, and I'm fairly convinced that's the wiser choice all around.

>So, what I'm interested in adding is a mechanism for attribute/authorisation verification for a known set of data - e.g. a query for validity of a given subject,atribute,attribute value combination.

I think you're taking a basic attribute query problem and making it more complex than it needs to be so that instead of it "just working", you need a new capability. You should avoid any new capabilities unless it's absolutely unavoidable, and I don't think it is here.

> This would allow, for example, collection of SSH public keys
> via web logins (either as released attributes or on a configuration page), and for verification of validity on every use of the private key.

Just query for some attribute representing the list of keys, and then you don't need anything more than a simple attribute query. No new spec.

>An alternate use case would be for validating sign-up data, so that manually collected attributes can be verified. For example, if the IdP authenticates a user, but doesn't release attributes for the real name, it would be useful for the SP to confirm that a subject is who they claim to be on the sign-up page.

The IdP saying that X=Y is the same as if it were releasing X=Y. The privacy argument is more around comparisons. Asking if somebody's age is over 18 is a useful feature since you don't have to get the birthdate. But that isn't really what you're proposing, and it definitely isn't necessary for an SSH use case.

-- Scott