Hello,
in my SP application i want to create an administrative section where setting up SAML.
In this section, ideally, an administrator could create a saml.config file, import metadata and export metadata.
Something similar to what you do in the Examples.
To create the saml.config, I set up a control like this:
but using, as guide, the code in the CreateConfiguration example, i noticed that i cannot set values for the AuthRequestSigned and the WantAssertionSigned element.
Could you please provide me infos about those two values and how to manage them?
thank you
Fabio
Hi Fabio,
The CreateConfiguration example creates local identity provider or service provider configuration. The two flags you refer to are part of the partner provider configuration in saml.config as these may vary from one partner provider to another. For example, you might sign authn requests sent to one partner identity provider but not the other.
The AuthnRequestsSigned would correspond to the SignAuthnRequest flag.
The WantAssertionsSIgned would correspond to the WantAssertionSigned flag. However, please note that there’s a WantAssertionOrResponseSigned flag that defaults to true. Generally it’s simply to expect either the SAML response or assertion to be signed rather than being specific.
Also, did you mean “Assertion Consumer Service Endpoint” rather than “Attribute Consumer Service Endpoint”?
[quote][/quote]
Hi!Hi Fabio,
The CreateConfiguration example creates local identity provider or service provider configuration. The two flags you refer to are part of the partner provider configuration in saml.config as these may vary from one partner provider to another. For example, you might sign authn requests sent to one partner identity provider but not the other.
The AuthnRequestsSigned would correspond to the SignAuthnRequest flag.
The WantAssertionsSIgned would correspond to the WantAssertionSigned flag. However, please note that there's a WantAssertionOrResponseSigned flag that defaults to true. Generally it's simply to expect either the SAML response or assertion to be signed rather than being specific.
Also, did you mean "Assertion Consumer Service Endpoint" rather than "Attribute Consumer Service Endpoint"?
The CreateConfiguration example creates local identity provider or service provider configuration. The two flags you refer to are part of the partner provider configuration in saml.config as these may vary from one partner provider to another. For example, you might sign authn requests sent to one partner identity provider but not the other.
The AuthnRequestsSigned would correspond to the SignAuthnRequest flag.
The WantAssertionsSIgned would correspond to the WantAssertionSigned flag. However, please note that there's a WantAssertionOrResponseSigned flag that defaults to true. Generally it's simply to expect either the SAML response or assertion to be signed rather than being specific.
Also, did you mean "Assertion Consumer Service Endpoint" rather than "Attribute Consumer Service Endpoint"?
yes, the label was incorrect: the right one is "Assertion Consumer Service Endpoint".
Now, I think i don't have a correct idea of how the configuration works: the differences between local SP (since we are implementing an SP) and Partner service provider.
I'll try to explain our need better. We have a SP (our app) and i want to configure it trough the saml.config. Let's say an initial configuration where we only define enpoints for SSO and SLO of our SP. For this, i wanted to use your CreateConfiguration example as a guide.
After that, using the partner Idp metadata, we need to include those information into this, just created, saml.config.
We also need to export our metadata to share with the Idp.. so, basically, create it from our saml.config and give it to the idp so that it can include those into its own configurations.
Since AuthnRequestsSigned and WantAssertionsSIgned are SP configurations, why do i should use a partner SP to configure them?
Thank you
Fabio
The SignAuthnRequest and WantAssertionSigned flags are actually part of the configuration. The reason for including these flags in the configuration rather than the local configuration is that it allows you to configure these on a per partner IdP basis. For example, one partner IdP may want SAML authn requests to be signed and another might not want them signed. If these flags were part of the local configuration you wouldn’t be able to perform different actions for each partner IdP.
The identity provider metadata has a WantAuthnRequestsSigned flag. When you import this metadata to create a configuration, it will set the SignAuthnRequest appropriately.
Regarding the WantAssertionsSigned, as I mentioned we have a WantAssertionOrResponseSigned flag that defaults to true. In our experience it’s simpler to just use this and we ensure either the SAML response or assertion is signed.
Therefore, this would mean in your administrator screen you would drop the AuthnRequestsSigned and WantAssertionsSigned.
[quote][/quote]
The SignAuthnRequest and WantAssertionSigned flags are actually part of the configuration. The reason for including these flags in the configuration rather than the local configuration is that it allows you to configure these on a per partner IdP basis. For example, one partner IdP may want SAML authn requests to be signed and another might not want them signed. If these flags were part of the local configuration you wouldn't be able to perform different actions for each partner IdP.
The identity provider metadata has a WantAuthnRequestsSigned flag. When you import this metadata to create a configuration, it will set the SignAuthnRequest appropriately.
Regarding the WantAssertionsSigned, as I mentioned we have a WantAssertionOrResponseSigned flag that defaults to true. In our experience it's simpler to just use this and we ensure either the SAML response or assertion is signed.
Therefore, this would mean in your administrator screen you would drop the AuthnRequestsSigned and WantAssertionsSigned.
The identity provider metadata has a WantAuthnRequestsSigned flag. When you import this metadata to create a configuration, it will set the SignAuthnRequest appropriately.
Regarding the WantAssertionsSigned, as I mentioned we have a WantAssertionOrResponseSigned flag that defaults to true. In our experience it's simpler to just use this and we ensure either the SAML response or assertion is signed.
Therefore, this would mean in your administrator screen you would drop the AuthnRequestsSigned and WantAssertionsSigned.
So, let me see if i got it right: my local SP configuration is a "plain" and simple configuration where i set the EntityID and the ACS; eventually also the certificats(s) and the SLO Service. And nothing alse.
Once i get the metadata from a PartnerIdP, those information are saved into my saml.config so that when my SP have to deal with this IdP it will behave accordingly ("Oh i have to talk to ADFS, it needs me to sign my SLO request, so let me sign it"): especially regarding the WantAuthRequestsSigned and the WantAssertionSigned attributes.
Especially, when a export my local SP metadata, this metadata will be created knowing previously the Idp i have to share this info to.
Is this scenario correct?
Thank you
Fabio
Your understanding is correct.
The SP metadata can be generic (ie apply to all partner identity providers). However, if for example, you specified AuthnRequestsSigned as false in the metadata, this may not be acceptable for some IdPs that want the authn requests signed. Metadata is good for sharing the entityID, certificates and URLs. Flags such as the AuthnRequestsSigned are more up for negotiation between the SP and IdP.
[quote][/quote]
Your understanding is correct.
The SP metadata can be generic (ie apply to all partner identity providers). However, if for example, you specified AuthnRequestsSigned as false in the metadata, this may not be acceptable for some IdPs that want the authn requests signed. Metadata is good for sharing the entityID, certificates and URLs. Flags such as the AuthnRequestsSigned are more up for negotiation between the SP and IdP.
The SP metadata can be generic (ie apply to all partner identity providers). However, if for example, you specified AuthnRequestsSigned as false in the metadata, this may not be acceptable for some IdPs that want the authn requests signed. Metadata is good for sharing the entityID, certificates and URLs. Flags such as the AuthnRequestsSigned are more up for negotiation between the SP and IdP.
Ok thank you for the explanation!
Fabio
You’re welcome.