O365 auth bypass
cantor.2 at osu.edu
Wed Apr 27 18:38:03 EDT 2016
On 4/27/16, 6:26 PM, "Ioannis Kakavas" <ikakavas at noc.grnet.gr> wrote:
>>federated protocol that mitigates this, and even the Shibboleth-defined
>>scope filtering idea only applies to some attributes.
>It could be applied to the attribute they are using.
I don't believe it was EPPN, was it?
There aren't many identifiers that are scoped. EPPN and eduPersonUniqueID are it. You can't just take any attribute that happens to end in a domain and treat it that way, because the whole community needs to recognize that semantic for things to work well.
The mail attribute for example is not scoped.
>>This is being misrepresented (and >dangerously so, IMHO)
>That's an overstatement IMHO.
When you call the blog article "The road to hell is paved with SAML Assertions", I think that's a pretty misleading title. Anybody reading that is going to immediately assume that the issue was a flaw in either SAML itself or their SAML implementation, and neither of those is true.
It's a deployment flaw, not a software mistake. If anything, I'd replace SAML Assertions in that title with "Cloud" and you'd have a much more accurate title.
>It's not claimed that the middleware would/should solve the issue. The write up is addressed to a general security aware audience, not to saml experts, and as though some things are simplified.
Well, obviously I think they're misrepresented, not simplified. I think a general audience would reach a very different conclusion from it.
>But you have to acknowledge the fact that if they used i.e. Shibboleth sp and the IDPEmail was scoped, they would be - by default - protected.
If the attribute wasn't defined somewhere authoritatively to be scoped, I wouldn't have told anybody that asked to define it to the software that way, and so they wouldn't be.
More information about the users