Sustainsys / Saml2

Saml2 Authentication services for ASP.NET
Other
960 stars 602 forks source link

The signature verified correctly with the key contained in the signature, but that key is not trusted. #669

Closed jmwdocx closed 7 years ago

jmwdocx commented 7 years ago

Hi,

We have successfully deployed Kentor.authservices to validate Okta SSO on Test and Prod, but when we have tried to make the same changes to our web,config file for Prod, we get (Y's replace Domain, X replace application, ___. replace the actual IP Address):

Exception information: Exception type: InvalidSignatureException Exception message: The signature verified correctly with the key contained in the signature, but that key is not trusted. at Kentor.AuthServices.XmlHelpers.VerifySignature(IEnumerable1 signingKeys, SignedXml signedXml, XmlElement signatureElement, Boolean validateCertificate) at Kentor.AuthServices.XmlHelpers.IsSignedByAny(XmlElement xmlElement, IEnumerable1 signingKeys, Boolean validateCertificate) at Kentor.AuthServices.Saml2P.Saml2Response.ValidateSignature(IOptions options) at Kentor.AuthServices.Saml2P.Saml2Response.Validate(IOptions options) at Kentor.AuthServices.Saml2P.Saml2Response.d__53.MoveNext() at System.Collections.Generic.List1..ctor(IEnumerable1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source) at Kentor.AuthServices.Saml2P.Saml2Response.GetClaims(IOptions options) at Kentor.AuthServices.WebSso.AcsCommand.ProcessResponse(IOptions options, Saml2Response samlResponse, StoredRequestState storedRequestState) at Kentor.AuthServices.WebSso.AcsCommand.Run(HttpRequestData request, IOptions options) at Kentor.AuthServices.HttpModule.Saml2AuthenticationModule.OnPostAuthenticateRequest(Object sender, EventArgs e) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Request information: Request URL: https://YYYYYYYYYY.com:443/XXXXX/AuthServices/Acs Request path: /XXXXX/AuthServices/Acs User host address: ---.---.---.--- User: Is authenticated: False Authentication Type: Thread account name: NT AUTHORITY\SYSTEM

We are using the same okta.cert as Test and Val, referring to it with the same path, and comparing the Val and Prod web.configs shows that the only changes are Okta's different URL/app key for the two different sites.

Here is the relevant portion of the Prod web.config:

<kentor.authServices entityId="https://YYYYYYYYYY/ensur/AuthServices" 

returnUrl="https://YYYYYYYYYY/XXXXX/login.aspx" authenticateRequestSigningBehavior="Always">
    <nameIdPolicy allowCreate="true" format="Persistent" />
    <metadata cacheDuration="0:0:42" validDuration="7.12:00:00" wantAssertionsSigned="true">
      <organization name="Kentor IT AB" displayName="Kentor" url="http://www.kentor.se" language="sv" />
      <contactPerson type="Other" email="info@kentor.se" />
      <requestedAttributes>
        <add friendlyName="XXXXX" name="XXXXX" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true" />
        <add name="Minimal" />
      </requestedAttributes>
    </metadata>
    <identityProviders>
      <!-- Use the info provided by Okta -->
      <add entityId="http://www.okta.com/exk1c7eo478JDuCGx0h8" 
           signOnUrl="https://YYYYYYYYYY.okta.com/app/XXXXX_1/[UniqueKey]/sso/saml" 
           allowUnsolicitedAuthnResponse="true" binding="HttpRedirect">
        <signingCertificate fileName="~\okta.cert" />
      </add>
    </identityProviders>
  </kentor.authServices>
  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://YYYYYYYYYY/XXXXX/AuthServices" />
      </audienceUris>
    </identityConfiguration>
  </system.identityModel>
  <!-- End of Implementing kentor.authServices -->
</configuration>

Any guidance would be greatly appreciated.

Thanks in Advance,

John W.

jmwdocx commented 7 years ago

For whatever reason, the portion of web.config in no displaying;

<kentor.authServices entityId="https://YYYYYYYYYY/ensur/AuthServices" 

returnUrl="https://YYYYYYYYYY/XXXXX/login.aspx" authenticateRequestSigningBehavior="Always">
    <nameIdPolicy allowCreate="true" format="Persistent" />
    <metadata cacheDuration="0:0:42" validDuration="7.12:00:00" wantAssertionsSigned="true">
      <organization name="Kentor IT AB" displayName="Kentor" url="http://www.kentor.se" language="sv" />
      <contactPerson type="Other" email="info@kentor.se" />
      <requestedAttributes>
        <add friendlyName="XXXXX" name="XXXXX" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true" />
        <add name="Minimal" />
      </requestedAttributes>
    </metadata>
    <identityProviders>
      <!-- Use the info provided by Okta -->
      <add entityId="http://www.okta.com/exk1c7eo478JDuCGx0h8" 
           signOnUrl="https://YYYYYYYYYY.okta.com/app/XXXXX_1/[UniqueKey]/sso/saml" 
           allowUnsolicitedAuthnResponse="true" binding="HttpRedirect">
        <signingCertificate fileName="~\okta.cert" />
      </add>
    </identityProviders>
  </kentor.authServices>
  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://YYYYYYYYYY/XXXXX/AuthServices" />
      </audienceUris>
    </identityConfiguration>
  </system.identityModel>
  <!-- End of Implementing kentor.authServices -->
</configuration>

webconfig.txt

explunit commented 7 years ago

Okta seems to support the metadata standard. Can you simply omit the signingCertificate element and let it read from the metadata? By default the entityId is used as the metadata location but you can also specify a different location using the metadataLocation property. If you use the default location (the entity id) you should set loadMetadata to true.

AndersAbel commented 7 years ago

The error message states that the certificate that was used to sign the response does not match the one in the configuration. Are you sure that it is the same okta.cert file that you should use for all environments?

It might also be that Okta changes to new keys regularly. In that case you should really use metadata as suggested above to automatically get the new keys.