Good Day,
We are trying to get ClaimTypes from metadata URL. We are using ITfoxtec.Identity.Saml2.MvcCore Version 4.7.1
Here the metadata
This is the method we are using to get metadata information.
entityDescriptor.ReadIdPSsoDescriptorFromUrl(new Uri(MetaDataUrl))
Here the return values
Is there any way to get ClaimTypes from IDPSSODescriptor?
Thanks
The metadata you are trying to read is WS-Federation and not SAML 2.0. The ITfoxtec Identity Saml2 component only support reading SAML 2.0 metadata.
Related
We are using the ITfoxtec SAML2 library for Single Sign On with SAML2 authentication for some of our external Clients.
So far we only have one client that wants SSO, but we anticipate that we will get more clients that want to use SSO, so my question is that can we store the setting in a Database rather than read from a Configuration file.
We would like to look up the values for each client from a data store and then build the SAML2 Configuration and then do the binding.
var binding = new Saml2RedirectBinding();
binding.SetRelayStateQuery(new Dictionary<string, string> { { "RelayState", relayStateReturnUrl ?? Url.Content("~/") } });
//The bindingResult is a SAML2 redirectBinding - this create a browser redirect to the IDP.
var bindingResult = binding.Bind(new Saml2AuthnRequest(_samlConfig));
So we would build out the Saml2Configuration our selves (Or perhaps store those in a Database table and look it up based on the client.
The idea is to pass in a custom SAMLConfiguration rather than reading it from the App settings.
Would this approach work, would the ITfoxtec have a sample for this approach ?
Multible IdP and RP support is implemented in FoxIDs in the SamlConfigurationLogic.cs class. You can either implement you own version of the SAML config logic or user FoxIDs to handle the multible IdP connections for your application.
Related questions and answers:
ITfoxtec SAML 2.0: Dynamic configuration
Load SAML2 configuration on the runtime instead of loading it on the Startup
I am using Spring SAML integration. I am getting below error when I tried to SAML logout without SingleLogout point.
I override the SAML method to check metadata has any SingleLogout point or not but it's not working.
Caused by: org.opensaml.saml2.metadata.provider.MetadataProviderException: IDP doesn't contain any SingleLogout endpoints
at org.springframework.security.saml.util.SAMLUtil.getLogoutBinding(SAMLUtil.java:108)
at org.springframework.security.saml.websso.SingleLogoutProfileImpl.sendLogoutRequest(SingleLogoutProfileImpl.java:66)
at org.springframework.security.saml.SAMLLogoutFilter.processLogout(SAMLLogoutFilter.java:140)
To properly override the lack of single logout endpoint in the metadata, you'd have to provide your own implementation of org.springframework.security.saml.websso.SingleLogoutProfile and inject it as a dependency in your application config. Certainly doable but quite a bit of effort for a problem that has a simpler solution: manually modify the metadata you received from the IdP and add the endpoint. (If the metadata is signed, you'll need to remove the signature).
We are trying to implement SSO, using OneLogin as the IdP with our Cisco Call Manager cluster using a single agreement for all the servers in the cluster.
This just basically means that our metadata file contains a separate AssertionConsumerService tag for every server in the cluster.
However we are hitting an issue where in the SAML response the Destination is not recognized as valid.
My question would be, in the case of multiple ACS' used, what would the destination field need to look like in the SAML response? Does the IdP need to recognize which consumer the request came from and dynamically change the destination in the response to be the correct one for the specific consumer?
Right now the SAML response looks something like this:
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://<CUCM_2>:8443/ssosp/saml/SSO/alias/<CUCM_2>https://<CUCM_2>:8443/ssosp/saml/SSO/alias/<CUCM_2>https://<IMP_1>:8443/ssosp/saml/SSO/alias/<IMP_1>https://<IMP_1>:8443/ssosp/saml/SSO/alias/<IMP_1>https://<CUCM_1>:8443/ssosp/saml/SSO/alias/<CUCM_1>https://<CUCM_1>:8443/ssosp/saml/SSO/alias/<CUCM_1>" ID="pfx117d2cec-f554-1fba-ff86-8db77b497e35" InResponseTo="s2ded98fb1a7423ea7bb1fcc95cf5c57ae3bf19684" IssueInstant="2019-02-18T16:06:06Z" Version="2.0">
and we get the same jumble for Recipient attribute in SubjectConfirmationData
With a proper cluster, you'd have a single ACS URL and the cluster would manage the user session between cluster members outside of SAML. I've not heard of multiple ACS URLs being used for a single SAML supporting SP. The IdP ( Onelogin ) needs to know specifically where to send the SAML response. I think you'll need to look at your cluster configuration and see whether it can be configured as a endpoint regardless of the cluster instance that initiates the SAML request.
Ah, but Cisco is special, don't you know? :)
I managed to get it working in the meantime and whoever is reading this thread in the future, I can confirm that OneLogin can now support Cisco clusters using a single cluster-wide metadata. But for any other IdP the setup is:
IdP requirements
CUCM only supports NameIDFormat as transient
HTTP-POST and HTTP-Redirect SAML bindings need to be enabled
SAML specification that allows for the definition of multiple AssertionConsumerService tags needs to be supported
Operation
When setting up SSO, within the metadata generated by CUCM if using cluster wide SSO mode, multiple AssertionConsumerService tags are defined. Two for each server in the cluster, one using the POST method and one using Redirect. Each ACS also has an Index tag, that starts at 0. This is sent to the IdP
When trying to authenticate a SAML request is sent to the IdP, within the request the AssertionConsumerServiceIndex field is set to the Index of the server from which the request was generated, as defined in the metadata originally provided to the IdP
The IdP then sends back a SAML response, in which the Destination and Recipient tags are set to match the Location tag from the metadata corresponding to the requesting server
I have a saml response that gives me azure active directory when doing the process with saml 2.0, the whole process is done normally, I send a saml request and the azure active directory returns the saml response, to do the whole process I have based on this guide, I've been reading a bit and I've noticed that Azure AD in the saml response sends the values within this tag:
<xenc:CipherData>
<xenc:CipherValue>VALUE HERE</xenc:CipherValue
</xenc:CipherData>
And not inside:
<AttributeStatement><Attribute Name="IDPEmail"><AttributeValue>administrator#contoso.com</AttributeValue></Attribute></AttributeStatement>
as specified in the documentation. The question is, how to get the true values that azure active directory is sent to me and not these encoded values, I am using Python 3 and Google App Engine, in addition to mentioning azure active directory and saml 2.0 to do the login process, I leave the SAML response complete in this url in case it serves to give a better context to my question.
As mentioned above, the SAML response you are getting is encrypted. Specifically Azure is encrypting its assertions (including the ones you are looking for) inside an encrypted body called CipherData.
You have two options:
1 - Disable SAML response encryption.
Azure AD calls SAML response encryption as SAML token encryption which is a bit confusing. You can follow this guide to disable the response. You must have uploaded an encryption public key/cert before.
2 - Configure your service provider to supported encrypted SAML responses.
The SAML token is encrypted.
You need to get the client side certificate used for this and use that to decrypt it.
In WSO2IS v4.6.0, the AuthnContextClassRef value is hardcoded to urn:oasis:names:tc:SAML:2.0:ac:classes:Password. In fact, the SAML SSO endpoint actually authenticates users via HTTPS by default and the AuthnContextClassRef value in this case should be urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport.
What's the best way to correct this or get this issue on WSO2's radar?
I've created a JIRA ticket for this issue: https://wso2.org/jira/browse/IDENTITY-2585
While waiting for an offical fix, you can override their DefaultSAML2SSOManager by specifiing your own class in repository/conf/security/application-authentication.xml with:
Parameter name="SAML2SSOManager">my.version.of.SAML2SSOManager
I use a slightly modified version of their DefaultSAML2SSOManager and am able to connect to our IDP.