my goal is to provide user access for an App registered at Azure Active Directory via an external IDP that supports only SAML 2.0. The App is an SPA with a node.js backend. Thats why we don't do it direct.
Unfortunately we are stuck with the error: Invalid value specified for property signingCertificate.
Configuration - i'm not sure as I dont have SAML Know-How:
Issuer URI: https://fed.hin.ch/saml/2.0/idp/
Passive authentication endpoint: https://fed.hin.ch/saml/2.0/idp/
Certificate: <I dont know - documentation by microsoft is unclear. The ID of the website? https://fed.hin.ch/saml/2.0/idp/, the whole certificate, a serial number as X.509 does not know ID? > We tried a lot.
A valid Certificate would be this:
Serial Number: 12fa001a6a9ca3686279c707835f39ba16f1f997
<ds:X509Certificate>MIIJeDCCB2CgAwIBAgIUEvoAGmqco2hieccHg185uhbx+ZcwDQYJKoZIhvcNAQELBQAwVjELMAkG
A1UEBhMCTkwxIDAeBgNVBAoMF1F1b1ZhZGlzIFRydXN0bGluayBCLlYuMSUwIwYDVQQDDBxRdW9W
YWRpcyBFdXJvcGUgRVYgU1NMIENBIEcxMB4XDTIxMTEwODE1NTAxNFoXDTIyMTEwODE2MDAwMFow
gc8xEzARBgsrBgEEAYI3PAIBAxMCQ0gxGDAWBgsrBgEEAYI3PAIBAgwHWsO8cmljaDEdMBsGA1UE
DwwUUHJpdmF0ZSBPcmdhbml6YXRpb24xGDAWBgNVBAUTD0NIRS0xMDMuNDg5LjIxODELMAkGA1UE
BhMCQ0gxEDAOBgNVBAgMB1rDvHJpY2gxFDASBgNVBAcMC1dhbGxpc2VsbGVuMRswGQYDVQQKDBJI
ZWFsdGggSW5mbyBOZXQgQUcxEzARBgNVBAMMCmZlZC5oaW4uY2gwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQDArafPFsVFKjkt4EYYztIdDqv3mSSv9D2IalQ0g7dtR9eUegpNp29bqkoQ
t+pMmvz2OAH2jBNN5x78swP6tO6mOJA2EeNWDfxciZQk8uaLiSMdGkQ6ilPyHrRYROFRc0fV5ArQ
pB94cTulfyi0EliKgMKGVFzCgLhMc19MICk0U9lYtpOTPopYKLiQTG98lyNDPOwgIqO9JZpyXBm6
Uv1SMCJ+i/mLci3LsneS1FukkCZ/I/iw7jwP+FW9fz17ep2oOTEar1R9R4rA3oAkxBjjjm580Z6Q
r/gtWTkH8lG+ZAX1MXqERrqz8cj7elW9fSTXDAZHtw2bUVz1JnW3VMrGLCbnwQVCLNjiMRHWLL8P
bCR7dAW7x917WzrAQd3I59O3SfELYYBr2msSpnBGT5Dpfrjl5GW1hQ4pWiOJt31qWqQMLUQjZ6RQ
AIUDi884xtuGd8gXD2t3Ey9SIyQG53ZEMs5lTmniIG63HPPLWE+9nuKnR2mL/rwqhdz7pB4Q8u3t
w92/YeOkNIBYUJQkDBupklHUOTnS7GwBtQyScIzqYJ4AcS7QQrl8MMTZ+VcjxkCwtJkN3riYmSzf
5tmjQ8TLqwQFssbGvob6/M/XG4NT69OOWiDefDHrSNqLer+IWGTw7xteMLMN+mSs/PadRJYxZwOs
L005VLjfGlRLgEOVwQIDAQABo4IDwjCCA74wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBRJPQ7c
ecXL2xKj1Q2r8s+pr+NmqTCBgwYIKwYBBQUHAQEEdzB1MEcGCCsGAQUFBzAChjtodHRwOi8vdHJ1
c3QucXVvdmFkaXNnbG9iYWwuY29tL3F1b3ZhZGlzZXVyb3BlZXZzc2xjYWcxLmNydDAqBggrBgEF
BQcwAYYeaHR0cDovL29jc3AucXVvdmFkaXNnbG9iYWwuY29tMBUGA1UdEQQOMAyCCmZlZC5oaW4u
Y2gwWgYDVR0gBFMwUTBGBgwrBgEEAb5YAAJkAQIwNjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5x
dW92YWRpc2dsb2JhbC5jb20vcmVwb3NpdG9yeTAHBgVngQwBATAdBgNVHSUEFjAUBggrBgEFBQcD
AgYIKwYBBQUHAwEwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL2NybC5xdW92YWRpc2dsb2JhbC5j
b20vcXVvdmFkaXNldXJvcGVldnNzbGNhZzEuY3JsMB0GA1UdDgQWBBQZ3tUpgmUlqoC58Qk1SwpX
HSVkkzAOBgNVHQ8BAf8EBAMCBaAwggH4BgorBgEEAdZ5AgQCBIIB6ASCAeQB4gB3ACl5vvCeOTkh
8FZzn2Old+W+V32cYAr4+U1dJlwlXceEAAABfQBHWSMAAAQDAEgwRgIhAJnRbOeI7rweNHglOBTZ
FPaBeBMVnwAAxAQbRG3UvkgGAiEA9ReQ4JpnJgTGoJeLGyqOFDbzsQic5tfPVA+sJj7FQBwAdwBG
pVXrdfqRIDC1oolp9PN9ESxBdL79SbiFq/L8cP5tRwAAAX0AR1jxAAAEAwBIMEYCIQDVLNTk/zJV
rhsbQhCcDVZk0iXef4aRw6D89V8OclDqFQIhAOF7qq36fIUQKvdc8hICHkrQ1g6fGwh+LzwSM8VP
Ow5cAHcAUaOw9f0BeZxWbbg3eI8MpHrMGyfL956IQpoN/tSLBeUAAAF9AEdaVwAABAMASDBGAiEA
slJDMwD7Wgm6mgpsruGEPSRVosjl9zDer5amfilJEeACIQDhZ0ZCU8Ap8vCY7pLIcg0cf2oXzxEf
NWyvdE3XH1jeNQB1AEHIyrHfIkZKEMahOglCh15OMYsbA+vrS8do8JBilgb2AAABfQBHWU8AAAQD
AEYwRAIgRmKixEvsjMosvmP37VWtaflm4SjKSHk2/zlSJ0KGDTwCICAyTzdZiptuoGuyW5zvFP41
uRig4OICrVAvqEKLL7oDMA0GCSqGSIb3DQEBCwUAA4ICAQBcH9xUpz7gVdxdDjrvzl6suKZ3Fvga
TmnT9tILc91fByuf5MoRRyn4vNGDwYeuCZzWwIaZ7N4FhXEIKYFwdr1GdJeZpHyGTTxvAvwo2lpS
iVUgIbwlMXftfXCQEwZUO+d1sFhSdbwJTivMA+ZpUJm/Uqnq2GRQVPTwttgzAKTGD2Eb8ud02kFd
BOHA5t106d7AC/1LsmHrAM/k2WJGTDCNyI86tCLFndPqV+u/quz4l0ZSJWQX8zALiGlNuJuLiLck
I00j9c8eWUHAIxoa69bOBjmqx5gciytyH24zRZ1E3HXnPM6rYmQUJXwA7fKTM22bLREYoInc5CcZ
fNJZvNghc36pf3P5icS9ZPuifwLmqXc0g8Vp6dAcCBPSKQqte0/728Nykc8gwfp8fSS6J+Dp40ZL
7CQYhAHMKgDgYKIZWNzVBRoCmkr/CbiALB64Smhl7vi9hCE+RjOWuCjjFJeuuiFJ9LTGYVMEqE4R
m6I1BhUSBDS4qJ/snMtAvplXcClmOkfyRmyUuufkw2LB+3/rT0NBcJYBF6TD/zKnkigcbcMJ6GPT
tox1POLCcvXPPjkAH0itHyGoczjdqUbC0kVX611ztOcAeP2+Q3kfkBr8ooFFL2/C/3jnIWoop2aA
7gxzKs/UhevMZvfmty2rBmCuPAy/ngcQStYlS0QkNENojQ==</ds:X509Certificate>```
Related
I have an Azure AD app registration that encrypts the JWT tokens it creates and this works well for API management. i decrypt and validate the token in API management with the following policy:
<validate-jwt header-name="Authorization" failed-validation-httpcode="401">
<openid-config url="https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration" />
<decryption-keys>
<key certificate-id="jwts" />
</decryption-keys>
<audiences>
<audience>!redacted!</audience>
</audiences>
<issuers>
<issuer>!redacted!</issuer>
</issuers>
<required-claims>
<claim name="roles" match="any">
<value>Accounts.Read.All</value>
</claim>
</required-claims>
</validate-jwt>
however, when I forward the request to the function app with easyauth enabled I get the following error:
{
"code": 401,
"message": "IDX10609: Decryption failed. No Keys tried: token: '[PII is hidden]'."
}
this makes sense because I haven't specified the decryption key anywhere but I can't seem to find the setting for this value anywhere? does anyone know how to do this?
Please check in case if any of the following are causes
Please check if you have passed App ID in the allowed audiences >:
api://{Azure Function AD App Id }.
Try giving authentication level as anonymous .Also check if function
key is given if the authentication level is not anonymous in your
case. Adding Authentication to Your HTTP Triggered Azure Functions -
DZone Security
Also after the token is received check its issuer endpoint and see if
the accesstokenacceptedversion has the same version.
And check if you need to turn on the system managed identity in apim
and change the inbound access policy to the same in the apim.
References:
Working with Azure Functions and (APIM)
offering (majorguidancesolutions.com)
Securing your Azure Functions App with API Management - Cloud
management at your fingertips (mscloud.be)
using-msal-net-to-call-an-azure-function-app-with-easy-auth-enabled
I am trying to setup saml sso configuration for my application which is deployed in websphere.
Idp- Azure AD
SP - Websphere application server when my target application deployed
Done TAI configuration as per the Ibm document . But when I hit the test button from idp I could see the saml response in network tab. but i couldn't login to my application and also didn't get any trace related to saml in log files also however i have enabled logs for saml in Troubleshoot. My doubt is sometimes am getting trace which are related to TAI during server stop. For each request should i be getting TAI trace ? and why my saml response not getting intercepted in TAI. How exactly the interception happen with saml response and how do we get to know that saml response got validated.
[15/4/21 16:18:42:855 IST] 00000096 TrustAssociat A SECJ0121I: Trust Association Init class com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor loaded successfully
acs url -> https://localhost:/browserTest (which is my actual target application url)
metadata and signing certificates also imported correctly.
Thanks for your help.
The acs URL has format like this:
https://<hostname>:<sslport>/samlsps/<any URI pattern string>
if you want to use your application URL
https://localhost:/browserTest
as acs URL, this UR must be able to accept HTTP POST.
I am integrating Okta in my React application for SSO. I use the following method to create token using redirect:
https://github.com/okta/okta-auth-js#tokengetwithredirectoptions
I am using https://www.npmjs.com/package/#okta/okta-auth-js package.
Users are directed to the Identity Provider (idp) in order to authenticate and then redirected to Okta once verification is successful.
The SSO works fine but when I keep the React application idle for sometime, I am getting the following error:
OAuthError - Unable to process the username transform. A required property is missing. Missing field email.
It looks like you have configured email as the incoming claim from your IDP but Okta can't find it in the incoming assertion/token.
idp-process.log
ERROR [org.opensaml.ws.security.provider.MandatoryAuthenticatedMessageRule:37] - Inbound message issuer was not authenticated.
shibd.log
ERROR OpenSAML.SOAPClient [109]: SOAP client detected a SAML error: (urn:oasis:names:tc:SAML:2.0:status:Responder) (Message did not meet security requirements)
ERROR Shibboleth.AttributeResolver.Query [109]: attribute authority returned a SAML error
The Shibboleth Authentication process is working properly. The Active Directory server (LDAP) is configured properly to work over SSL, which was verified using LDP.exe. I also coded a simple Java program to try to connect to the Active Directory server over SSL protocol. I was able to connect to the server using port 636, passed user credentials including password, and the server responded properly.
Certificates are already trusted by corresponding JVM cacerts.
Setup instructions are already followed as documented from https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverLDAPDataConnector
However, there is still an error during Attribute query from the Active Directory server. Below are snippet of the configurations.
Any idea as to why there is an error on the Attribute Query?
Thanks.
attribute-resolver.xml
<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
ldapURL="ldaps://WIN-1GB01UK5SL6.VECISADTEST.com"
baseDN="CN=Users,DC=vecisadtest,DC=com"
principal="Administrator#vecisadtest.com"
principalCredential="XXX"
useStartTLS="false"
>
<dc:FilterTemplate>
<![CDATA[
(uid=$requestContext.principalName)
]]>
</dc:FilterTemplate>
<StartTLSTrustCredential xsi:type="sec:X509Filesystem"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="UA_AD_CA_Certificate">
<sec:Certificate>C:\Progs\ShibbolethIdP\certs\VECISADTEST.pem</sec:Certificate>
</StartTLSTrustCredential>
<StartTLSAuthenticationCredential xsi:type="sec:X509Filesystem"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="IdPtoLDAPCredential">
<sec:PrivateKey>C:\Progs\ShibbolethIdP\credentials\idp.key</sec:PrivateKey>
<sec:Certificate>C:\Progs\ShibbolethIdP\credentials\idp.crt</sec:Certificate>
</StartTLSAuthenticationCredential>
</resolver:DataConnector>
login.config
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="WIN-1GB01UK5SL6.VECISADTEST.com"
port="636"
base="CN=Users,DC=vecisadtest,DC=com"
tls="false"
serviceCredential="XXX"
userRoleAttribute="sAMAccountName"
serviceUser="Administrator#vecisadtest.com"
ssl="true"
subtreeSearch = "true"
userField="sAMAccountName";
idp-metadata.xml
<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idp.janet.org:8444/idp/profile/SAML1/SOAP/AttributeQuery"/><AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://idp.janet.org:8444/idp/profile/SAML2/SOAP/AttributeQuery"/>
Thanks.
The issue was resolved by updating the config file shibboleth2.xml on the Service Provider. The signing attribute must be set to true.
[Shibboleth Service Provider install location] \etc\shibboleth\shibboleth2.xml
SPConfig > ApplicationDefaults#signing
Default installation of Shibboleth Service Provider 2.5.2, signing attribute is false.
I did SSO of OpenAM and SalesForce.com (SFDC)
I have installed OpenAM-Client SDK to retrieve SAML Assertion from OpenAM.
I used this assertion data to generate SAML response required for SalesForce. When I pass this data to SFDC. I got error message for SAML.
“Failed: Signature Invalid/Configured Certificate Mismatch”
I used same certificate and signature data which I got from OpenAM-client SDK public API assertion.
At time of SSO configuration with SDFC. I used default certificate (test cert) provided by OpenAM.
Is there any way to retrieve test certificate and its signature from OpenAM ?
Run one of the failing SAML assertions through the SAML Validation tool inside Single Sign-On Settings in SFDC; you should get a slightly more useful error. The most likely cause of this is that you have not uploaded the correct certificate to SFDC as part of your SSO setup. Make sure the "Identity Provider Certificate" section of "Single Sign-On Settings" matches the cert contained in the assertion.