New customers - really, really like the product so far. However, we are having a problem with the test setup needed before release to customers for QA verification.
We are an SP, and we are now going to offer SP-Initiated SAML to our customers where they have the IdP (mostly ADFS 2 and 3). We have no control over the IdPs (in general). I went with the low-level API for development where we are going to be expecting SAML 2 assertions. Initial development for Shibboleth IdP SSO went well; it runs without issue in testing for end-to-end. We have a test server (Gluu Community Edition) and the code setup seemed to work fine. With Shibboleth we won’t have issues with RelayState, so we are using it there. That one is a pure SAML 2 - SAML 2 setup and everything works as designed.
Took the lessons learned there and wrote the first run at ADFS connector with the same SP-Initiated code as a base. Using Azure as a test bed since we don’t have other ADFS IdP to play with at present. [Company is using SAML in IdP-Initated mode with other SPs that we work with, but there is no test bed that I have access to.]
I refactored the logic for ADFS clients so that we won’t have the RelayState - not sure the sophistication of clients and don’t want to have roadblocks there. Setting up Azure ADFS was very laborious. But it is working AFAICT in the cloud now and I see the metadata from ADFS. However, I immediately hit a roadblock with AuthNRequest when called from first-stage test server; there is something in Azure ADFS where the ADFS service doesn’t like the domain name in the cert (as far as I can tell). I’ve tried it a couple of different ways but I always get Event 364 with the error:
Encountered error during federation passive request
System.Uri.FormatException q3-k**********.com. The format of the URI could not be determined.
I read in the forum that Azure doesn’t require AuthN to be encrypted so I tried to send it without being encrypted but the result was the same.
I’m hoping you guys have seen this type of thing before. I’ve tried with and without https:// at the beginning of my cert’s FQDN. The setup of the ADFS Trust is complete - Windows did not complain about the trust that was setup. The cert was accepted. Still, no go in testing so far - I always get Event 364.
We could have literally dozens of customers to be using some form of this service - I really, really need to get this tested for at least ADFS 3 => Saml Assertions before we talk to the first customer to test. I need to finish debugging the code that looks over the LDAP and custom data that we are going to be requiring our customers to send to us.
You’ve seen this URI problem previously? If you need my metadata from Azure please create a support case I’ll send it there.
Thanks
[quote][/quote]
New customers - really, really like the product so far. However, we are having a problem with the test setup needed before release to customers for QA verification.
We are an SP, and we are now going to offer SP-Initiated SAML to our customers where they have the IdP (mostly ADFS 2 and 3). We have no control over the IdPs (in general). I went with the low-level API for development where we are going to be expecting SAML 2 assertions. Initial development for Shibboleth IdP SSO went well; it runs without issue in testing for end-to-end. We have a test server (Gluu Community Edition) and the code setup seemed to work fine. With Shibboleth we won't have issues with RelayState, so we are using it there. That one is a pure SAML 2 - SAML 2 setup and everything works as designed.
Took the lessons learned there and wrote the first run at ADFS connector with the same SP-Initiated code as a base. Using Azure as a test bed since we don't have other ADFS IdP to play with at present. [Company *is* using SAML in IdP-Initated mode with other SPs that we work with, but there is no test bed that I have access to.]
I refactored the logic for ADFS clients so that we won't have the RelayState - not sure the sophistication of clients and don't want to have roadblocks there. Setting up Azure ADFS was very laborious. But it is working AFAICT in the cloud now and I see the metadata from ADFS. However, I immediately hit a roadblock with AuthNRequest when called from first-stage test server; there is something in Azure ADFS where the ADFS service doesn't like the domain name in the cert (as far as I can tell). I've tried it a couple of different ways but I always get Event 364 with the error:
Encountered error during federation passive request
System.Uri.FormatException q3-k**********.com. The format of the URI could not be determined.
I read in the forum that Azure doesn't require AuthN to be encrypted so I tried to send it without being encrypted but the result was the same.
I'm hoping you guys have seen this type of thing before. I've tried with and without https:// at the beginning of my cert's FQDN. The setup of the ADFS Trust is complete - Windows did not complain about the trust that was setup. The cert was accepted. Still, no go in testing so far - I always get Event 364.
We could have literally dozens of customers to be using some form of this service - I really, really need to get this tested for at least ADFS 3 => Saml Assertions before we talk to the first customer to test. I need to finish debugging the code that looks over the LDAP and custom data that we are going to be requiring our customers to send to us.
You've seen this URI problem previously? If you need my metadata from Azure please create a support case I'll send it there.
Thanks
We are an SP, and we are now going to offer SP-Initiated SAML to our customers where they have the IdP (mostly ADFS 2 and 3). We have no control over the IdPs (in general). I went with the low-level API for development where we are going to be expecting SAML 2 assertions. Initial development for Shibboleth IdP SSO went well; it runs without issue in testing for end-to-end. We have a test server (Gluu Community Edition) and the code setup seemed to work fine. With Shibboleth we won't have issues with RelayState, so we are using it there. That one is a pure SAML 2 - SAML 2 setup and everything works as designed.
Took the lessons learned there and wrote the first run at ADFS connector with the same SP-Initiated code as a base. Using Azure as a test bed since we don't have other ADFS IdP to play with at present. [Company *is* using SAML in IdP-Initated mode with other SPs that we work with, but there is no test bed that I have access to.]
I refactored the logic for ADFS clients so that we won't have the RelayState - not sure the sophistication of clients and don't want to have roadblocks there. Setting up Azure ADFS was very laborious. But it is working AFAICT in the cloud now and I see the metadata from ADFS. However, I immediately hit a roadblock with AuthNRequest when called from first-stage test server; there is something in Azure ADFS where the ADFS service doesn't like the domain name in the cert (as far as I can tell). I've tried it a couple of different ways but I always get Event 364 with the error:
Encountered error during federation passive request
System.Uri.FormatException q3-k**********.com. The format of the URI could not be determined.
I read in the forum that Azure doesn't require AuthN to be encrypted so I tried to send it without being encrypted but the result was the same.
I'm hoping you guys have seen this type of thing before. I've tried with and without https:// at the beginning of my cert's FQDN. The setup of the ADFS Trust is complete - Windows did not complain about the trust that was setup. The cert was accepted. Still, no go in testing so far - I always get Event 364.
We could have literally dozens of customers to be using some form of this service - I really, really need to get this tested for at least ADFS 3 => Saml Assertions before we talk to the first customer to test. I need to finish debugging the code that looks over the LDAP and custom data that we are going to be requiring our customers to send to us.
You've seen this URI problem previously? If you need my metadata from Azure please create a support case I'll send it there.
Thanks
Reading over my question I realize that masked URL is confusing. Of course we are using a real, live URL with a Thawte Cert on that machine. I'm only masking the URL in this message as it is a public forum. q3 is our first-level QA qualification server, but it (of course) doesn't contain asterisks in the real world.
Thanks
I don’t think this is related to domain names in certificates.
Our internal testing is done with self-signed certificates whose domain names don’t necessarily match with our test environment.
Please ensure that the relying party configured in ADFS has an identifier that exactly matches the Issuer field value included in the authn request.
If that’s not the issue, please send the following details to support@componentspace.com mentioning this topic:
1. ADFS federation metadata.
2. Screen shots of the ADFS relying party property tabs.
3. Any ADFS event log entries.
4. Our SAML log file (http://www.componentspace.com/Forums/17/Enabing-SAML-Trace).
[quote][/quote]
I don't think this is related to domain names in certificates.
Our internal testing is done with self-signed certificates whose domain names don't necessarily match with our test environment.
Please ensure that the relying party configured in ADFS has an identifier that exactly matches the Issuer field value included in the authn request.
If that's not the issue, please send the following details to support@componentspace.com mentioning this topic:
1. ADFS federation metadata.
2. Screen shots of the ADFS relying party property tabs.
3. Any ADFS event log entries.
4. Our SAML log file (http://www.componentspace.com/Forums/17/Enabing-SAML-Trace).
Our internal testing is done with self-signed certificates whose domain names don't necessarily match with our test environment.
Please ensure that the relying party configured in ADFS has an identifier that exactly matches the Issuer field value included in the authn request.
If that's not the issue, please send the following details to support@componentspace.com mentioning this topic:
1. ADFS federation metadata.
2. Screen shots of the ADFS relying party property tabs.
3. Any ADFS event log entries.
4. Our SAML log file (http://www.componentspace.com/Forums/17/Enabing-SAML-Trace).
That was exactly the issue. The typo there caused this issue.
Thanks for your help. I hope that this becomes a KB response for this particular problem in ADFS.
Thanks again.
You’re welcome.
Sometimes ADFS error messages can be a bit cryptic. 