<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 23, 2014 at 1:33 PM, David Chadwick <span dir="ltr"><<a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Adam<br>
<span class=""><br>
On 23/12/2014 17:34, Adam Young wrote:<br>
> On 12/23/2014 11:34 AM, David Chadwick wrote:<br>
>> Hi guys<br>
>><br>
>> we now have the ABFAB federation protocol working with Keystone, using a<br>
>> modified mod_auth_kerb plugin for Apache (available from the project<br>
>> Moonshot web site). However, we did not change Keystone configuration<br>
>> from its original SAML federation configuration, when it was talking to<br>
>> SAML IDPs, using mod_shibboleth. Neither did we modify the Keystone code<br>
>> (which I believe had to be done for OpenID connect.) We simply replaced<br>
>> mod_shibboleth with mod_auth_kerb and talked to a completely different<br>
>> IDP with a different protocol. And everything worked just fine.<br>
>><br>
>> Consequently Keystone is broken, since you can configure it to trust a<br>
>> particular IDP, talking a particular protocol, but Apache will happily<br>
>> talk to another IDP, using a different protocol, and Keystone cannot<br>
>> tell the difference and will happily accept the authenticated user.<br>
>> Keystone should reject any authenticated user who does not come from the<br>
>> trusted IDP talking the correct protocol. Otherwise there is no point in<br>
>> configuring Keystone with this information, if it is ignored by Keystone.<br>
> The IDP and the Protocol should be passed from HTTPD in env vars. Can<br>
> you confirm/deny that this is the case now?<br>
<br>
</span>What is passed from Apache is the 'PATH_INFO' variable, and it is set to<br>
the URL of Keystone that is being protected, which in our case is<br>
/OS-FEDERATION/identity_providers/KentProxy/protocols/saml2/auth<br>
<br>
There are also the following arguments passed to Keystone<br>
'wsgiorg.routing_args': (<routes.util.URLGenerator object at<br>
0x7ffaba339190>, {'identity_provider': u'KentProxy', 'protocol': u'saml2'})<br>
<br>
and<br>
<br>
'PATH_TRANSLATED':<br>
'/var/www/keystone/main/v3/OS-FEDERATION/identity_providers/KentProxy/protocols/saml2/auth'<br>
<br>
So Apache is telling Keystone that it has protected the URL that<br>
Keystone has configured to be protected.<br>
<br>
However, Apache has been configured to protect this URL with the ABFAB<br>
protocol and the local Radius server, rather than the KentProxy IdP and<br>
the SAML2 protocol. So we could say that Apache is lying to Keystone,<br>
and because Keystone trusts Apache, then Keystone trusts Apache's lies<br>
and wrongly thinks that the correct IDP and protocol were used.<br>
<br>
The only sure way to protect Keystone from a wrongly or mal-configured<br>
Apache is to have end to end security, where Keystone gets a token from<br>
the IDP that it can validate, to prove that it is the trusted IDP that<br>
it is talking to. In other words, if Keystone is given the original<br>
signed SAML assertion from the IDP, it will know for definite that the<br>
user was authenticated by the trusted IDP using the trusted protocol<br></blockquote><div><br></div><div>So the "bug" is a misconfiguration, not an actual bug. The goal was to trust and leverage httpd, not reimplement it and all it's extensions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
regards<br>
<br>
David<br>
<span class=""><br>
><br>
> On the Apache side we are looking to expand the set of variables set.<br>
> <a href="http://www.freeipa.org/page/Environment_Variables#Proposed_Additional_Variables" target="_blank">http://www.freeipa.org/page/Environment_Variables#Proposed_Additional_Variables</a><br>
><br>
><br>
<br>
</span>The original SAML assertion<br>
<div class="HOEnZb"><div class="h5">><br>
> mod_shib does support Shib-Identity-Provider :<br>
><br>
><br>
> <a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess#NativeSPAttributeAccess-CustomSPVariables" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess#NativeSPAttributeAccess-CustomSPVariables</a><br>
><br>
><br>
> Which should be sufficient: if the user is coming in via mod_shib, they<br>
> are using SAML.<br>
><br>
><br>
><br>
>><br>
>> BTW, we are using the Juno release. We should fix this bug in Kilo.<br>
>><br>
>> As I have been saying for many months, Keystone does not know anything<br>
>> about SAML or ABFAB or OpenID Connect protocols, so there is currently<br>
>> no point in configuring this information into Keystone. Keystone is only<br>
>> aware of environmental parameters coming from Apache. So this is the<br>
>> protocol that Keystone recognises. If you want Keystone to try to<br>
>> control the federation protocol and IDPs used by Apache, then you will<br>
>> need the Apache plugins to pass the name of the IDP and the protocol<br>
>> being used as environmental parameters to Keystone, and then Keystone<br>
>> can check that the ones that it has been configured to trust, are<br>
>> actually being used by Apache.<br>
>><br>
>> regards<br>
>><br>
>> David<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>