Open ObjectiveTruth opened 7 years ago
Thanks for the suggestion @ObjectiveTruth.
Usually an IDP will offer a metadata link to their xml containing all the configuration parameters for a SAML library to use for quick configuration and incase something changes at the IDP level, it doesn't have to manually updated to the SPs.
Do you have an example of this XML configuration that I could take a look at?
For sure, there's one available here on this gist
<EntityDescriptor entityID="https://idp.example.com/idp/shibboleth">
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:mace:shibboleth:1.0 urn:oasis:names:tc:SAML:2.0:protocol">
<Extensions>
<shibmd:Scope regexp="false" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0">idp.example.com</shibmd:Scope>
<mdui:UIInfo xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui">
<mdui:DisplayName xml:lang="ja">idp-example</mdui:DisplayName>
<mdui:DisplayName xml:lang="en">idp-example Inc.</mdui:DisplayName>
<mdui:Logo height="75" width="200">http://www.idp-example.co.jp/images/logo.png</mdui:Logo>
<mdui:InformationURL xml:lang="ja">http://www.idp-example.co.jp/</mdui:InformationURL>
<mdui:InformationURL xml:lang="en">http://www.idp-example.co.jp/</mdui:InformationURL>
<mdui:PrivacyStatementURL xml:lang="ja">http://www.idp-example.co.jp/</mdui:PrivacyStatementURL>
<mdui:PrivacyStatementURL xml:lang="en">http://www.idp-example.co.jp/</mdui:PrivacyStatementURL>
<mdui:Keywords xml:lang="en">category:location:others</mdui:Keywords>
</mdui:UIInfo>
<mdui:DiscoHints xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui">
<mdui:IPHint>xxx.xxx.xxx.xxx/32</mdui:IPHint>
<mdui:IPHint>yyy.yyy.yyy.yyy/32</mdui:IPHint>
<mdui:DomainHint>www.idp-example.co.jp</mdui:DomainHint>
<mdui:DomainHint>idp.example.com</mdui:DomainHint>
</mdui:DiscoHints>
</Extensions>
<KeyDescriptor>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIISOMECERTSM9Xvw==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://idp.example.com/idp/profile/Shibboleth/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.example.com/idp/profile/SAML2/POST/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://idp.example.com/idp/profile/SAML2/Redirect/SSO"/>
</IDPSSODescriptor>
<AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<Extensions>
<shibmd:Scope regexp="false" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0">idp.example.com</shibmd:Scope>
</Extensions>
<KeyDescriptor>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIISOMECERTSM9Xvw==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idp.example.com:8443/idp/profile/SAML1/SOAP/AttributeQuery"/>
<AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.example.com:8443/idp/profile/SAML2/SOAP/AttributeQuery"/>
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
</AttributeAuthorityDescriptor>
</EntityDescriptor>
I'm sure you must of come across it working with SAML, usually the easiest way for 2 parties to communicate is for the SP and IdP to exchange metadata so they can trust each other.
The above is an example of an IdP but an SP has its own, for example for simpleSAML
, the url to find the metadata is at /simplesaml/module.php/saml/sp/metadata.php/default-sp
And simplesaml allows importing of IdP metadata aswell
I've started this feature here: https://github.com/pantheon-systems/wp-saml-auth/compare/master...laupow:feature/sp-metadata-endpoint
It's heavily adapted from a few pieces in the humanmade/wp-simple-saml plugin.
I think exposing the SP metadata only makes sense when using the internal
connection type. Not sure though.
The changes add an endpoint at /saml/sp/metadata/
which spit out XML metadata:
@danielbachhuber is this direction worth continuing for the plugin?
@ObjectiveTruth I think this issue was originally opened to import settings from the IdP's metadata URL. It looks like your code exports the settings from WordPress / OneLogin. Is this correct? If so, I'm not quite sure what the use case is for that.
That looks correct; my comments belong in a separate issue. I'll move them soon.
@laupow is this feature merged ??
I've started this feature here: master...laupow:feature/sp-metadata-endpoint
Heya,
Usually an IDP will offer a metadata link to their xml containing all the configuration parameters for a SAML library to use for quick configuration and incase something changes at the IDP level, it doesn't have to manually updated to the SPs.
I think it'd be a great idea to have the plugin take a metadata url and keep a copy locally that is refreshed every so often.
I'm thinking, a reference implementation could be the Moodle WP saml plugin
great library btw 👍