OpenAM integration with Python djangosaml

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenAM integration with Python djangosaml

Anish Narang

Hi,

I have setup OpenAM Idp and registered a Python djangosaml SP in the same circle of trust with their metadata. On sending the authentication request from the SP, I end up with an error ‘Invalid signature in Request’. And this is what the openam debug logs show :

WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/25/2016 11:41:17:265 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128

What could be the cause for this and how do I fix it?

Thanks



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenAM integration with Python djangosaml

Eivind Mikkelsen-2
If you don't have a lot of traffic on your OpenAM IdP currently, I suggest that you enable message level debug logging for the Federation module using Debug.jsp (no restart required), retest authentication and check the SignatureMethod and DigestMethod Algorithm for the logged AuthnRequest in the Federation log.

Best regards
Eivind Mikkelsen

On Wed, May 25, 2016 at 12:15 PM, Anish Narang <[hidden email]> wrote:

Hi,

I have setup OpenAM Idp and registered a Python djangosaml SP in the same circle of trust with their metadata. On sending the authentication request from the SP, I end up with an error ‘Invalid signature in Request’. And this is what the openam debug logs show :

WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/25/2016 11:41:17:265 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128

What could be the cause for this and how do I fix it?

Thanks



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenAM integration with Python djangosaml

Nicolas Seigneur
I suspect the SP is configured with 256 Key Size while the the OpenAM is configured with the default 128 Key Size.

In Federation Tab, click on your IDP and look for Key Size, set it to 256, restart OpenAM and I believe this would fix this issue.

Nicolas Seigneur
Indigo Consulting Canada

On Wed, May 25, 2016 at 9:32 AM, Eivind Mikkelsen <[hidden email]> wrote:
If you don't have a lot of traffic on your OpenAM IdP currently, I suggest that you enable message level debug logging for the Federation module using Debug.jsp (no restart required), retest authentication and check the SignatureMethod and DigestMethod Algorithm for the logged AuthnRequest in the Federation log.

Best regards
Eivind Mikkelsen

On Wed, May 25, 2016 at 12:15 PM, Anish Narang <[hidden email]> wrote:

Hi,

I have setup OpenAM Idp and registered a Python djangosaml SP in the same circle of trust with their metadata. On sending the authentication request from the SP, I end up with an error ‘Invalid signature in Request’. And this is what the openam debug logs show :

WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/25/2016 11:41:17:265 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128

What could be the cause for this and how do I fix it?

Thanks



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam




--
-------------------------------------------------
Nicolas Seigneur
Indigo Technologies Canada, Inc.
mobile: +1.514.965.4890

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenAM integration with Python djangosaml

Anish Narang

Thanks for the suggestion. I changed the key size to 256 and the encryption algorithm to http://www.w3.org/2001/04/xmlenc#aes256-cbc on the IdP. However, I still end up with the same error. Here is a complete description of it as given by the Federation debug logs of OpenAM : 


FMSigProvider.verify: The cert contained in the document is trusted
libSAML2:05/26/2016 10:57:07:435 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
validateCertificate :  CRL check is not configured. Just return it is good.
libSAML2:05/26/2016 10:57:07:436 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/26/2016 10:57:07:436 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128
at com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:360)
at com.sun.identity.saml2.xmlsig.FMSigProvider.verify(FMSigProvider.java:329)
at com.sun.identity.saml2.protocol.impl.RequestAbstractImpl.isSignatureValid(RequestAbstractImpl.java:313)
at org.forgerock.openam.saml2.UtilProxySAMLAuthenticator.authenticate(UtilProxySAMLAuthenticator.java:182)
at com.sun.identity.saml2.profile.IDPSSOFederate.process(IDPSSOFederate.java:233)
at com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:142)
at com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:102)
at org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFederate_jsp.java:158)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:106)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.forgerock.openam.audit.context.AuditContextFilter.doFilter(AuditContextFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:93)
at org.apache.xml.security.algorithms.SignatureAlgorithm.verify(SignatureAlgorithm.java:301)
at org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:723)
at org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:660)
at com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:348)
... 42 more
Caused by: java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
at sun.security.rsa.RSASignature.engineVerify(RSASignature.java:189)
at java.security.Signature$Delegate.engineVerify(Signature.java:1219)
at java.security.Signature.verify(Signature.java:652)
at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:91)
... 46 more

Could it possibly be a Java version error? Any help will be appreciated.

Thanks



From: [hidden email] <[hidden email]> on behalf of Nicolas Seigneur <[hidden email]>
Sent: Wednesday, May 25, 2016 7:20 PM
To: Users
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml
 
I suspect the SP is configured with 256 Key Size while the the OpenAM is configured with the default 128 Key Size.

In Federation Tab, click on your IDP and look for Key Size, set it to 256, restart OpenAM and I believe this would fix this issue.

Nicolas Seigneur
Indigo Consulting Canada

On Wed, May 25, 2016 at 9:32 AM, Eivind Mikkelsen <[hidden email]> wrote:
If you don't have a lot of traffic on your OpenAM IdP currently, I suggest that you enable message level debug logging for the Federation module using Debug.jsp (no restart required), retest authentication and check the SignatureMethod and DigestMethod Algorithm for the logged AuthnRequest in the Federation log.

Best regards
Eivind Mikkelsen

On Wed, May 25, 2016 at 12:15 PM, Anish Narang <[hidden email]> wrote:

Hi,

I have setup OpenAM Idp and registered a Python djangosaml SP in the same circle of trust with their metadata. On sending the authentication request from the SP, I end up with an error ‘Invalid signature in Request’. And this is what the openam debug logs show :

WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/25/2016 11:41:17:265 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128

What could be the cause for this and how do I fix it?

Thanks



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam




--
-------------------------------------------------
Nicolas Seigneur
Indigo Technologies Canada, Inc.
mobile: +1.514.965.4890

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenAM integration with Python djangosaml

Bernie Jones
In reply to this post by Anish Narang
Do you just need to re-export and import your metadata after the change...?
(Also, do you actually need request signing?)

Regards,
Bernie



-------- Original message --------
From Anish Narang <[hidden email]>
Date: 26/05/2016 06:54 (GMT+00:00)
To Users <[hidden email]>
Subject Re: [OpenAM] OpenAM integration with Python djangosaml


Thanks for the suggestion. I changed the key size to 256 and the encryption algorithm to http://www.w3.org/2001/04/xmlenc#aes256-cbc on the IdP. However, I still end up with the same error. Here is a complete description of it as given by the Federation debug logs of OpenAM : 


FMSigProvider.verify: The cert contained in the document is trusted
libSAML2:05/26/2016 10:57:07:435 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
validateCertificate :  CRL check is not configured. Just return it is good.
libSAML2:05/26/2016 10:57:07:436 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/26/2016 10:57:07:436 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128
at com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:360)
at com.sun.identity.saml2.xmlsig.FMSigProvider.verify(FMSigProvider.java:329)
at com.sun.identity.saml2.protocol.impl.RequestAbstractImpl.isSignatureValid(RequestAbstractImpl.java:313)
at org.forgerock.openam.saml2.UtilProxySAMLAuthenticator.authenticate(UtilProxySAMLAuthenticator.java:182)
at com.sun.identity.saml2.profile.IDPSSOFederate.process(IDPSSOFederate.java:233)
at com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:142)
at com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:102)
at org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFederate_jsp.java:158)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:106)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.forgerock.openam.audit.context.AuditContextFilter.doFilter(AuditContextFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:93)
at org.apache.xml.security.algorithms.SignatureAlgorithm.verify(SignatureAlgorithm.java:301)
at org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:723)
at org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:660)
at com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:348)
... 42 more
Caused by: java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
at sun.security.rsa.RSASignature.engineVerify(RSASignature.java:189)
at java.security.Signature$Delegate.engineVerify(Signature.java:1219)
at java.security.Signature.verify(Signature.java:652)
at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:91)
... 46 more

Could it possibly be a Java version error? Any help will be appreciated.

Thanks



From: [hidden email] <[hidden email]> on behalf of Nicolas Seigneur <[hidden email]>
Sent: Wednesday, May 25, 2016 7:20 PM
To: Users
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml
 
I suspect the SP is configured with 256 Key Size while the the OpenAM is configured with the default 128 Key Size.

In Federation Tab, click on your IDP and look for Key Size, set it to 256, restart OpenAM and I believe this would fix this issue.

Nicolas Seigneur
Indigo Consulting Canada

On Wed, May 25, 2016 at 9:32 AM, Eivind Mikkelsen <[hidden email]> wrote:
If you don't have a lot of traffic on your OpenAM IdP currently, I suggest that you enable message level debug logging for the Federation module using Debug.jsp (no restart required), retest authentication and check the SignatureMethod and DigestMethod Algorithm for the logged AuthnRequest in the Federation log.

Best regards
Eivind Mikkelsen

On Wed, May 25, 2016 at 12:15 PM, Anish Narang <[hidden email]> wrote:

Hi,

I have setup OpenAM Idp and registered a Python djangosaml SP in the same circle of trust with their metadata. On sending the authentication request from the SP, I end up with an error ‘Invalid signature in Request’. And this is what the openam debug logs show :

WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/25/2016 11:41:17:265 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128

What could be the cause for this and how do I fix it?

Thanks



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam




--
-------------------------------------------------
Nicolas Seigneur
Indigo Technologies Canada, Inc.
mobile: +1.514.965.4890

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenAM integration with Python djangosaml

Anish Narang

I re imported the metadata and also restarted Tomcat and OpenAM. 


Once I set the AuthenticationRequestsSigned to false in the SP metadata, I get the following error : 


ERROR: Cannot recover key
libSAML2:05/26/2016 12:45:07:547 PM IST: Thread[http-bio-8080-exec-4,5,main]: TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]
ERROR: FMSigProvider.sign: Either input xml string or id value or private key is null.
libSAML2:05/26/2016 12:45:07:547 PM IST: Thread[http-bio-8080-exec-4,5,main]: TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]
ERROR: IDPSSOFederate.generateAssertionResponseUnable to do sso or federation.
com.sun.identity.saml2.common.SAML2Exception: Null input.

Is that the right  way to do it?


Thanks





From: [hidden email] <[hidden email]> on behalf of Bernie Jones <[hidden email]>
Sent: Thursday, May 26, 2016 11:41 AM
To: Users
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml
 
Do you just need to re-export and import your metadata after the change...?
(Also, do you actually need request signing?)

Regards,
Bernie



-------- Original message --------
From Anish Narang <[hidden email]>
Date: 26/05/2016 06:54 (GMT+00:00)
To Users <[hidden email]>
Subject Re: [OpenAM] OpenAM integration with Python djangosaml


Thanks for the suggestion. I changed the key size to 256 and the encryption algorithm to http://www.w3.org/2001/04/xmlenc#aes256-cbc on the IdP. However, I still end up with the same error. Here is a complete description of it as given by the Federation debug logs of OpenAM : 


FMSigProvider.verify: The cert contained in the document is trusted
libSAML2:05/26/2016 10:57:07:435 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
validateCertificate :  CRL check is not configured. Just return it is good.
libSAML2:05/26/2016 10:57:07:436 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/26/2016 10:57:07:436 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128
at com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:360)
at com.sun.identity.saml2.xmlsig.FMSigProvider.verify(FMSigProvider.java:329)
at com.sun.identity.saml2.protocol.impl.RequestAbstractImpl.isSignatureValid(RequestAbstractImpl.java:313)
at org.forgerock.openam.saml2.UtilProxySAMLAuthenticator.authenticate(UtilProxySAMLAuthenticator.java:182)
at com.sun.identity.saml2.profile.IDPSSOFederate.process(IDPSSOFederate.java:233)
at com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:142)
at com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:102)
at org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFederate_jsp.java:158)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:106)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.forgerock.openam.audit.context.AuditContextFilter.doFilter(AuditContextFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:93)
at org.apache.xml.security.algorithms.SignatureAlgorithm.verify(SignatureAlgorithm.java:301)
at org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:723)
at org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:660)
at com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:348)
... 42 more
Caused by: java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
at sun.security.rsa.RSASignature.engineVerify(RSASignature.java:189)
at java.security.Signature$Delegate.engineVerify(Signature.java:1219)
at java.security.Signature.verify(Signature.java:652)
at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:91)
... 46 more

Could it possibly be a Java version error? Any help will be appreciated.

Thanks



From: [hidden email] <[hidden email]> on behalf of Nicolas Seigneur <[hidden email]>
Sent: Wednesday, May 25, 2016 7:20 PM
To: Users
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml
 
I suspect the SP is configured with 256 Key Size while the the OpenAM is configured with the default 128 Key Size.

In Federation Tab, click on your IDP and look for Key Size, set it to 256, restart OpenAM and I believe this would fix this issue.

Nicolas Seigneur
Indigo Consulting Canada

On Wed, May 25, 2016 at 9:32 AM, Eivind Mikkelsen <[hidden email]> wrote:
If you don't have a lot of traffic on your OpenAM IdP currently, I suggest that you enable message level debug logging for the Federation module using Debug.jsp (no restart required), retest authentication and check the SignatureMethod and DigestMethod Algorithm for the logged AuthnRequest in the Federation log.

Best regards
Eivind Mikkelsen

On Wed, May 25, 2016 at 12:15 PM, Anish Narang <[hidden email]> wrote:

Hi,

I have setup OpenAM Idp and registered a Python djangosaml SP in the same circle of trust with their metadata. On sending the authentication request from the SP, I end up with an error ‘Invalid signature in Request’. And this is what the openam debug logs show :

WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/25/2016 11:41:17:265 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128

What could be the cause for this and how do I fix it?

Thanks



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam




--
-------------------------------------------------
Nicolas Seigneur
Indigo Technologies Canada, Inc.
mobile: +1.514.965.4890

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenAM integration with Python djangosaml

Bernie Jones

The requirement for requests from the SP to be signed is a configuration setting in the IDP – if it’s set in the IDP then the SP must sign and include the public key in the metadata for the IDP to validate.

(So leaving the requirement set in the IDP and disabling signing in the SP would cause the problem seen).

 

The requirement for assertions from the IDP to be signed is likewise a configuration setting in the SP – if it’s set then the IDP must sign assertions and include the public key in its metadata for the SP to validate.

 

So, my thought was just  that if you don’t actually need requests to be signed then you could disable this requirement in the IDP. That wouldn’t actually result in a fix for the original 128/256 problem but rather work around it if acceptable security-wise.

 

I would anticipate however that you would still want your assertions from the IDP signed so would still need to have compatible hashing algorithms supported on both sides to support that.

 

Hope that helps.

 

Regards,

Bernie

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Anish Na
Sent: 26 May 2016 08:20
To: Users
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml

 

I re imported the metadata and also restarted Tomcat and OpenAM. 

 

Once I set the AuthenticationRequestsSigned to false in the SP metadata, I get the following error : 

 

ERROR: Cannot recover key

libSAML2:05/26/2016 12:45:07:547 PM IST: Thread[http-bio-8080-exec-4,5,main]: TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]

ERROR: FMSigProvider.sign: Either input xml string or id value or private key is null.

libSAML2:05/26/2016 12:45:07:547 PM IST: Thread[http-bio-8080-exec-4,5,main]: TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]

ERROR: IDPSSOFederate.generateAssertionResponseUnable to do sso or federation.

com.sun.identity.saml2.common.SAML2Exception: Null input.

 

Is that the right  way to do it?

 

Thanks

 

 


From: [hidden email] <[hidden email]> on behalf of Bernie Jones <[hidden email]>
Sent: Thursday, May 26, 2016 11:41 AM
To: Users
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml

 

Do you just need to re-export and import your metadata after the change...?

(Also, do you actually need request signing?)

 

Regards,

Bernie




-------- Original message --------
From Anish Narang <[hidden email]>
Date: 26/05/2016 06:54 (GMT+00:00)
To Users <[hidden email]>
Subject Re: [OpenAM] OpenAM integration with Python djangosaml

Thanks for the suggestion. I changed the key size to 256 and the encryption algorithm to http://www.w3.org/2001/04/xmlenc#aes256-cbc on the IdP. However, I still end up with the same error. Here is a complete description of it as given by the Federation debug logs of OpenAM : 

 

FMSigProvider.verify: The cert contained in the document is trusted

libSAML2:05/26/2016 10:57:07:435 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]

validateCertificate :  CRL check is not configured. Just return it is good.

libSAML2:05/26/2016 10:57:07:436 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]

WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128

Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128

libSAML2:05/26/2016 10:57:07:436 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]

ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.

com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128

at com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:360)

at com.sun.identity.saml2.xmlsig.FMSigProvider.verify(FMSigProvider.java:329)

at com.sun.identity.saml2.protocol.impl.RequestAbstractImpl.isSignatureValid(RequestAbstractImpl.java:313)

at org.forgerock.openam.saml2.UtilProxySAMLAuthenticator.authenticate(UtilProxySAMLAuthenticator.java:182)

at com.sun.identity.saml2.profile.IDPSSOFederate.process(IDPSSOFederate.java:233)

at com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:142)

at com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:102)

at org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFederate_jsp.java:158)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:106)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at org.forgerock.openam.audit.context.AuditContextFilter.doFilter(AuditContextFilter.java:51)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)

at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)

at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:745)

Caused by: org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128

Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128

at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:93)

at org.apache.xml.security.algorithms.SignatureAlgorithm.verify(SignatureAlgorithm.java:301)

at org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:723)

at org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:660)

at com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:348)

... 42 more

Caused by: java.security.SignatureException: Signature length not correct: got 256 but was expecting 128

at sun.security.rsa.RSASignature.engineVerify(RSASignature.java:189)

at java.security.Signature$Delegate.engineVerify(Signature.java:1219)

at java.security.Signature.verify(Signature.java:652)

at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:91)

... 46 more

 

Could it possibly be a Java version error? Any help will be appreciated.

 

Thanks

 


From: [hidden email] <[hidden email]> on behalf of Nicolas Seigneur <[hidden email]>
Sent: Wednesday, May 25, 2016 7:20 PM
To: Users
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml

 

I suspect the SP is configured with 256 Key Size while the the OpenAM is configured with the default 128 Key Size.

 

In Federation Tab, click on your IDP and look for Key Size, set it to 256, restart OpenAM and I believe this would fix this issue.

 

Nicolas Seigneur

Indigo Consulting Canada

 

On Wed, May 25, 2016 at 9:32 AM, Eivind Mikkelsen <[hidden email]> wrote:

If you don't have a lot of traffic on your OpenAM IdP currently, I suggest that you enable message level debug logging for the Federation module using Debug.jsp (no restart required), retest authentication and check the SignatureMethod and DigestMethod Algorithm for the logged AuthnRequest in the Federation log.

 

Best regards

Eivind Mikkelsen

 

On Wed, May 25, 2016 at 12:15 PM, Anish Narang <[hidden email]> wrote:

Hi,

I have setup OpenAM Idp and registered a Python djangosaml SP in the same circle of trust with their metadata. On sending the authentication request from the SP, I end up with an error ‘Invalid signature in Request’. And this is what the openam debug logs show :

WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/25/2016 11:41:17:265 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128

What could be the cause for this and how do I fix it?

Thanks

 

 

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam

 


_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam



 

--

-------------------------------------------------

Nicolas Seigneur
Indigo Technologies Canada, Inc.
mobile: +1.514.
965.4890




Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com





Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenAM integration with Python djangosaml

Anish Narang

Thanks for the information. 


The previous error of Null input was produced when requests signed setting was disabled in the IdP as well as the metadata of the SP. Does that mean I have gone wrong some where else? I cant quite understand the error of private key being null.


Regrds,
Anish




From: [hidden email] <[hidden email]> on behalf of Bernie Jones <[hidden email]>
Sent: Thursday, May 26, 2016 1:19 PM
To: 'Users'
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml
 

The requirement for requests from the SP to be signed is a configuration setting in the IDP – if it’s set in the IDP then the SP must sign and include the public key in the metadata for the IDP to validate.

(So leaving the requirement set in the IDP and disabling signing in the SP would cause the problem seen).

 

The requirement for assertions from the IDP to be signed is likewise a configuration setting in the SP – if it’s set then the IDP must sign assertions and include the public key in its metadata for the SP to validate.

 

So, my thought was just  that if you don’t actually need requests to be signed then you could disable this requirement in the IDP. That wouldn’t actually result in a fix for the original 128/256 problem but rather work around it if acceptable security-wise.

 

I would anticipate however that you would still want your assertions from the IDP signed so would still need to have compatible hashing algorithms supported on both sides to support that.

 

Hope that helps.

 

Regards,

Bernie

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Anish Na
Sent: 26 May 2016 08:20
To: Users
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml

 

I re imported the metadata and also restarted Tomcat and OpenAM. 

 

Once I set the AuthenticationRequestsSigned to false in the SP metadata, I get the following error : 

 

ERROR: Cannot recover key

libSAML2:05/26/2016 12:45:07:547 PM IST: Thread[http-bio-8080-exec-4,5,main]: TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]

ERROR: FMSigProvider.sign: Either input xml string or id value or private key is null.

libSAML2:05/26/2016 12:45:07:547 PM IST: Thread[http-bio-8080-exec-4,5,main]: TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]

ERROR: IDPSSOFederate.generateAssertionResponseUnable to do sso or federation.

com.sun.identity.saml2.common.SAML2Exception: Null input.

 

Is that the right  way to do it?

 

Thanks

 

 


From: [hidden email] <[hidden email]> on behalf of Bernie Jones <[hidden email]>
Sent: Thursday, May 26, 2016 11:41 AM
To: Users
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml

 

Do you just need to re-export and import your metadata after the change...?

(Also, do you actually need request signing?)

 

Regards,

Bernie




-------- Original message --------
From Anish Narang <[hidden email]>
Date: 26/05/2016 06:54 (GMT+00:00)
To Users <[hidden email]>
Subject Re: [OpenAM] OpenAM integration with Python djangosaml

Thanks for the suggestion. I changed the key size to 256 and the encryption algorithm to http://www.w3.org/2001/04/xmlenc#aes256-cbc on the IdP. However, I still end up with the same error. Here is a complete description of it as given by the Federation debug logs of OpenAM : 

 

FMSigProvider.verify: The cert contained in the document is trusted

libSAML2:05/26/2016 10:57:07:435 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]

validateCertificate :  CRL check is not configured. Just return it is good.

libSAML2:05/26/2016 10:57:07:436 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]

WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128

Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128

libSAML2:05/26/2016 10:57:07:436 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]

ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.

com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128

at com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:360)

at com.sun.identity.saml2.xmlsig.FMSigProvider.verify(FMSigProvider.java:329)

at com.sun.identity.saml2.protocol.impl.RequestAbstractImpl.isSignatureValid(RequestAbstractImpl.java:313)

at org.forgerock.openam.saml2.UtilProxySAMLAuthenticator.authenticate(UtilProxySAMLAuthenticator.java:182)

at com.sun.identity.saml2.profile.IDPSSOFederate.process(IDPSSOFederate.java:233)

at com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:142)

at com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:102)

at org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFederate_jsp.java:158)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:106)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at org.forgerock.openam.audit.context.AuditContextFilter.doFilter(AuditContextFilter.java:51)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)

at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)

at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:745)

Caused by: org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128

Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128

at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:93)

at org.apache.xml.security.algorithms.SignatureAlgorithm.verify(SignatureAlgorithm.java:301)

at org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:723)

at org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:660)

at com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:348)

... 42 more

Caused by: java.security.SignatureException: Signature length not correct: got 256 but was expecting 128

at sun.security.rsa.RSASignature.engineVerify(RSASignature.java:189)

at java.security.Signature$Delegate.engineVerify(Signature.java:1219)

at java.security.Signature.verify(Signature.java:652)

at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:91)

... 46 more

 

Could it possibly be a Java version error? Any help will be appreciated.

 

Thanks

 


From: [hidden email] <[hidden email]> on behalf of Nicolas Seigneur <[hidden email]>
Sent: Wednesday, May 25, 2016 7:20 PM
To: Users
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml

 

I suspect the SP is configured with 256 Key Size while the the OpenAM is configured with the default 128 Key Size.

 

In Federation Tab, click on your IDP and look for Key Size, set it to 256, restart OpenAM and I believe this would fix this issue.

 

Nicolas Seigneur

Indigo Consulting Canada

 

On Wed, May 25, 2016 at 9:32 AM, Eivind Mikkelsen <[hidden email]> wrote:

If you don't have a lot of traffic on your OpenAM IdP currently, I suggest that you enable message level debug logging for the Federation module using Debug.jsp (no restart required), retest authentication and check the SignatureMethod and DigestMethod Algorithm for the logged AuthnRequest in the Federation log.

 

Best regards

Eivind Mikkelsen

 

On Wed, May 25, 2016 at 12:15 PM, Anish Narang <[hidden email]> wrote:

Hi,

I have setup OpenAM Idp and registered a Python djangosaml SP in the same circle of trust with their metadata. On sending the authentication request from the SP, I end up with an error ‘Invalid signature in Request’. And this is what the openam debug logs show :

WARNING: FMSigProvider.isValidSignature: XML signature validation failed due to org.apache.xml.security.signature.XMLSignatureException: Signature length not correct: got 256 but was expecting 128
Original Exception was java.security.SignatureException: Signature length not correct: got 256 but was expecting 128
libSAML2:05/25/2016 11:41:17:265 AM IST: Thread[http-bio-8080-exec-10,5,main]: TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
ERROR: UtilProxySAMLAuthenticator.authenticate: authn request verification failed.
com.sun.identity.saml2.common.SAML2Exception: Signature length not correct: got 256 but was expecting 128

What could be the cause for this and how do I fix it?

Thanks

 

 

_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam

 


_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam



 

--

-------------------------------------------------

Nicolas Seigneur
Indigo Technologies Canada, Inc.
mobile: +1.514.
965.4890




Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com





Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenAM integration with Python djangosaml

Bernhard Thalmayr
Most likely OpenAM could not initialize the SAML keystore.

The private key is needed if you perform response / assertion signing at
the IdP.

-Bernhard

Am 26/05/16 um 10:02 schrieb Anish Narang:

> Thanks for the information.
>
>
> The previous error of Null input was produced when requests signed
> setting was disabled in the IdP as well as the metadata of the SP. Does
> that mean I have gone wrong some where else? I cant quite understand the
> error of private key being null.
>
>
> Regrds,
> Anish
>
>
>
> ------------------------------------------------------------------------
> *From:* [hidden email] <[hidden email]> on
> behalf of Bernie Jones <[hidden email]>
> *Sent:* Thursday, May 26, 2016 1:19 PM
> *To:* 'Users'
> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>  
>
> The requirement for *requests* from the SP to be signed is a
> configuration setting in the IDP – if it’s set in the IDP then the SP
> must sign and include the public key in the metadata for the IDP to
> validate.
>
> (So leaving the requirement set in the IDP and disabling signing in the
> SP would cause the problem seen).
>
>  
>
> The requirement for *assertions* from the IDP to be signed is likewise a
> configuration setting in the SP – if it’s set then the IDP must sign
> assertions and include the public key in its metadata for the SP to
> validate.
>
>  
>
> So, my thought was just  that if you don’t actually need requests to be
> signed then you could disable this requirement in the IDP. That wouldn’t
> actually result in a fix for the original 128/256 problem but rather
> work around it if acceptable security-wise.
>
>  
>
> I would anticipate however that you would still want your assertions
> from the IDP signed so would still need to have compatible hashing
> algorithms supported on both sides to support that.
>
>  
>
> Hope that helps.
>
>  
>
> Regards,
>
> Bernie
>
>  
>
> *From:*[hidden email]
> [mailto:[hidden email]] *On Behalf Of *Anish Na
> *Sent:* 26 May 2016 08:20
> *To:* Users
> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>
>  
>
> I re imported the metadata and also restarted Tomcat and OpenAM.
>
>  
>
> Once I set the AuthenticationRequestsSigned to false in the SP metadata,
> I get the following error :
>
>  
>
> ERROR: Cannot recover key
>
> libSAML2:05/26/2016 12:45:07:547 PM IST:
> Thread[http-bio-8080-exec-4,5,main]:
> TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]
>
> ERROR: FMSigProvider.sign: Either input xml string or id value or
> private key is null.
>
> libSAML2:05/26/2016 12:45:07:547 PM IST:
> Thread[http-bio-8080-exec-4,5,main]:
> TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]
>
> ERROR: IDPSSOFederate.generateAssertionResponseUnable to do sso or
> federation.
>
> com.sun.identity.saml2.common.SAML2Exception: Null input.
>
>  
>
> Is that the right  way to do it?
>
>  
>
> Thanks
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> *From:*[hidden email] <[hidden email]> on
> behalf of Bernie Jones <[hidden email]>
> *Sent:* Thursday, May 26, 2016 11:41 AM
> *To:* Users
> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>
>  
>
> Do you just need to re-export and import your metadata after the change...?
>
> (Also, do you actually need request signing?)
>
>  
>
> Regards,
>
> Bernie
>
>
>
>
> -------- Original message --------
>>From Anish Narang <[hidden email]>
> Date: 26/05/2016 06:54 (GMT+00:00)
> To Users <[hidden email]>
> Subject Re: [OpenAM] OpenAM integration with Python djangosaml
>
> Thanks for the suggestion. I changed the key size to 256 and the
> encryption algorithm to http://www.w3.org/2001/04/xmlenc#aes256-cbc on
> the IdP. However, I still end up with the same error. Here is a complete
> description of it as given by the Federation debug logs of OpenAM :
>
>  
>
> FMSigProvider.verify: The cert contained in the document is trusted
>
> libSAML2:05/26/2016 10:57:07:435 AM IST:
> Thread[http-bio-8080-exec-10,5,main]:
> TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
>
> validateCertificate :  CRL check is not configured. Just return it is good.
>
> libSAML2:05/26/2016 10:57:07:436 AM IST:
> Thread[http-bio-8080-exec-10,5,main]:
> TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
>
> WARNING: FMSigProvider.isValidSignature: XML signature validation failed
> due to org.apache.xml.security.signature.XMLSignatureException:
> Signature length not correct: got 256 but was expecting 128
>
> Original Exception was java.security.SignatureException: Signature
> length not correct: got 256 but was expecting 128
>
> libSAML2:05/26/2016 10:57:07:436 AM IST:
> Thread[http-bio-8080-exec-10,5,main]:
> TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
>
> ERROR: UtilProxySAMLAuthenticator.authenticate: authn request
> verification failed.
>
> com.sun.identity.saml2.common.SAML2Exception: Signature length not
> correct: got 256 but was expecting 128
>
> at
> com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:360)
>
> at
> com.sun.identity.saml2.xmlsig.FMSigProvider.verify(FMSigProvider.java:329)
>
> at
> com.sun.identity.saml2.protocol.impl.RequestAbstractImpl.isSignatureValid(RequestAbstractImpl.java:313)
>
> at
> org.forgerock.openam.saml2.UtilProxySAMLAuthenticator.authenticate(UtilProxySAMLAuthenticator.java:182)
>
> at
> com.sun.identity.saml2.profile.IDPSSOFederate.process(IDPSSOFederate.java:233)
>
> at
> com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:142)
>
> at
> com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:102)
>
> at
> org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFederate_jsp.java:158)
>
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
>
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
>
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
> at
> org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
> at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:106)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
> at
> org.forgerock.openam.audit.context.AuditContextFilter.doFilter(AuditContextFilter.java:51)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
>
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
>
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
>
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)
>
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
>
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
>
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>
> at java.lang.Thread.run(Thread.java:745)
>
> Caused by: org.apache.xml.security.signature.XMLSignatureException:
> Signature length not correct: got 256 but was expecting 128
>
> Original Exception was java.security.SignatureException: Signature
> length not correct: got 256 but was expecting 128
>
> at
> org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:93)
>
> at
> org.apache.xml.security.algorithms.SignatureAlgorithm.verify(SignatureAlgorithm.java:301)
>
> at
> org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:723)
>
> at
> org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:660)
>
> at
> com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:348)
>
> ... 42 more
>
> Caused by: java.security.SignatureException: Signature length not
> correct: got 256 but was expecting 128
>
> at sun.security.rsa.RSASignature.engineVerify(RSASignature.java:189)
>
> at java.security.Signature$Delegate.engineVerify(Signature.java:1219)
>
> at java.security.Signature.verify(Signature.java:652)
>
> at
> org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:91)
>
> ... 46 more
>
>  
>
> Could it possibly be a Java version error? Any help will be appreciated.
>
>  
>
> Thanks
>
>  
>
> ------------------------------------------------------------------------
>
> *From:*[hidden email] <[hidden email]> on
> behalf of Nicolas Seigneur <[hidden email]>
> *Sent:* Wednesday, May 25, 2016 7:20 PM
> *To:* Users
> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>
>  
>
> I suspect the SP is configured with 256 Key Size while the the OpenAM is
> configured with the default 128 Key Size.
>
>  
>
> In Federation Tab, click on your IDP and look for Key Size, set it to
> 256, restart OpenAM and I believe this would fix this issue.
>
>  
>
> Nicolas Seigneur
>
> Indigo Consulting Canada
>
>  
>
> On Wed, May 25, 2016 at 9:32 AM, Eivind Mikkelsen <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> If you don't have a lot of traffic on your OpenAM IdP currently, I
> suggest that you enable message level debug logging for the Federation
> module using Debug.jsp (no restart required), retest authentication and
> check the SignatureMethod and DigestMethod Algorithm for the logged
> AuthnRequest in the Federation log.
>
>  
>
> Best regards
>
> Eivind Mikkelsen
>
>  
>
> On Wed, May 25, 2016 at 12:15 PM, Anish Narang <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     I have setup OpenAM Idp and registered a Python djangosaml SP in the
>     same circle of trust with their metadata. On sending the
>     authentication request from the SP, I end up with an error ‘Invalid
>     signature in Request’. And this is what the openam debug logs show :
>
>     WARNING: FMSigProvider.isValidSignature: XML signature validation
>     failed due to
>     org.apache.xml.security.signature.XMLSignatureException: Signature
>     length not correct: got 256 but was expecting 128
>     Original Exception was java.security.SignatureException: Signature
>     length not correct: got 256 but was expecting 128
>     libSAML2:05/25/2016 11:41:17:265 AM IST:
>     Thread[http-bio-8080-exec-10,5,main]:
>     TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
>     ERROR: UtilProxySAMLAuthenticator.authenticate: authn request
>     verification failed.
>     com.sun.identity.saml2.common.SAML2Exception: Signature length not
>     correct: got 256 but was expecting 128
>
>     What could be the cause for this and how do I fix it?
>
>     Thanks
>
>      
>
>      
>
>     _______________________________________________
>     Visit the OpenAM forum at
>     https://forgerock.org/forum/fr-projects/openam/
>     OpenAM mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.forgerock.org/mailman/listinfo/openam
>
>  
>
>
> _______________________________________________
> Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
> OpenAM mailing list
> [hidden email] <mailto:[hidden email]>
> https://lists.forgerock.org/mailman/listinfo/openam
>
>
>
>  
>
> --
>
> -------------------------------------------------
>
> Nicolas Seigneur
> Indigo Technologies Canada, Inc.
> mobile: +1.514.965.4890
>
> [hidden email] <mailto:[hidden email]>
> www.indigoconsulting.ca <http://www.indigoconsulting.ca/>
>
>
>
> ------------------------------------------------------------------------
> Avast logo <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
>
> ------------------------------------------------------------------------
> Avast logo
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
>
>
>
> _______________________________________________
> Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
> OpenAM mailing list
> [hidden email]
> https://lists.forgerock.org/mailman/listinfo/openam
>


--
Painstaking Minds
IT-Consulting Bernhard Thalmayr
Herxheimer Str. 5, 83620 Vagen (Munich area), Germany
Tel: +49 (0)8062 7769174
Mobile: +49 (0)176 55060699

[hidden email] - Solution Architect
http://www.xing.com/profile/Bernhard_Thalmayr
http://de.linkedin.com/in/bernhardthalmayr

This e-mail may contain confidential and/or privileged information.If
you are not the intended recipient (or have received this email in
error) please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenAM integration with Python djangosaml

Anish Narang
Yes you're right. The SAML response is being created and the error is caused while signing.

The keystore is accessible using the default settings on the CLI so Im not sure whats going wrong. How do I fix the issue?

Thanks


________________________________________
From: [hidden email] <[hidden email]> on behalf of Bernhard Thalmayr <[hidden email]>
Sent: Thursday, May 26, 2016 6:26 PM
To: [hidden email]
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml

Most likely OpenAM could not initialize the SAML keystore.

The private key is needed if you perform response / assertion signing at
the IdP.

-Bernhard

Am 26/05/16 um 10:02 schrieb Anish Narang:

> Thanks for the information.
>
>
> The previous error of Null input was produced when requests signed
> setting was disabled in the IdP as well as the metadata of the SP. Does
> that mean I have gone wrong some where else? I cant quite understand the
> error of private key being null.
>
>
> Regrds,
> Anish
>
>
>
> ------------------------------------------------------------------------
> *From:* [hidden email] <[hidden email]> on
> behalf of Bernie Jones <[hidden email]>
> *Sent:* Thursday, May 26, 2016 1:19 PM
> *To:* 'Users'
> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>
>
> The requirement for *requests* from the SP to be signed is a
> configuration setting in the IDP – if it’s set in the IDP then the SP
> must sign and include the public key in the metadata for the IDP to
> validate.
>
> (So leaving the requirement set in the IDP and disabling signing in the
> SP would cause the problem seen).
>
>
>
> The requirement for *assertions* from the IDP to be signed is likewise a
> configuration setting in the SP – if it’s set then the IDP must sign
> assertions and include the public key in its metadata for the SP to
> validate.
>
>
>
> So, my thought was just  that if you don’t actually need requests to be
> signed then you could disable this requirement in the IDP. That wouldn’t
> actually result in a fix for the original 128/256 problem but rather
> work around it if acceptable security-wise.
>
>
>
> I would anticipate however that you would still want your assertions
> from the IDP signed so would still need to have compatible hashing
> algorithms supported on both sides to support that.
>
>
>
> Hope that helps.
>
>
>
> Regards,
>
> Bernie
>
>
>
> *From:*[hidden email]
> [mailto:[hidden email]] *On Behalf Of *Anish Na
> *Sent:* 26 May 2016 08:20
> *To:* Users
> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>
>
>
> I re imported the metadata and also restarted Tomcat and OpenAM.
>
>
>
> Once I set the AuthenticationRequestsSigned to false in the SP metadata,
> I get the following error :
>
>
>
> ERROR: Cannot recover key
>
> libSAML2:05/26/2016 12:45:07:547 PM IST:
> Thread[http-bio-8080-exec-4,5,main]:
> TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]
>
> ERROR: FMSigProvider.sign: Either input xml string or id value or
> private key is null.
>
> libSAML2:05/26/2016 12:45:07:547 PM IST:
> Thread[http-bio-8080-exec-4,5,main]:
> TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]
>
> ERROR: IDPSSOFederate.generateAssertionResponseUnable to do sso or
> federation.
>
> com.sun.identity.saml2.common.SAML2Exception: Null input.
>
>
>
> Is that the right  way to do it?
>
>
>
> Thanks
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:*[hidden email] <[hidden email]> on
> behalf of Bernie Jones <[hidden email]>
> *Sent:* Thursday, May 26, 2016 11:41 AM
> *To:* Users
> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>
>
>
> Do you just need to re-export and import your metadata after the change...?
>
> (Also, do you actually need request signing?)
>
>
>
> Regards,
>
> Bernie
>
>
>
>
> -------- Original message --------
>>From Anish Narang <[hidden email]>
> Date: 26/05/2016 06:54 (GMT+00:00)
> To Users <[hidden email]>
> Subject Re: [OpenAM] OpenAM integration with Python djangosaml
>
> Thanks for the suggestion. I changed the key size to 256 and the
> encryption algorithm to http://www.w3.org/2001/04/xmlenc#aes256-cbc on
> the IdP. However, I still end up with the same error. Here is a complete
> description of it as given by the Federation debug logs of OpenAM :
>
>
>
> FMSigProvider.verify: The cert contained in the document is trusted
>
> libSAML2:05/26/2016 10:57:07:435 AM IST:
> Thread[http-bio-8080-exec-10,5,main]:
> TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
>
> validateCertificate :  CRL check is not configured. Just return it is good.
>
> libSAML2:05/26/2016 10:57:07:436 AM IST:
> Thread[http-bio-8080-exec-10,5,main]:
> TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
>
> WARNING: FMSigProvider.isValidSignature: XML signature validation failed
> due to org.apache.xml.security.signature.XMLSignatureException:
> Signature length not correct: got 256 but was expecting 128
>
> Original Exception was java.security.SignatureException: Signature
> length not correct: got 256 but was expecting 128
>
> libSAML2:05/26/2016 10:57:07:436 AM IST:
> Thread[http-bio-8080-exec-10,5,main]:
> TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
>
> ERROR: UtilProxySAMLAuthenticator.authenticate: authn request
> verification failed.
>
> com.sun.identity.saml2.common.SAML2Exception: Signature length not
> correct: got 256 but was expecting 128
>
> at
> com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:360)
>
> at
> com.sun.identity.saml2.xmlsig.FMSigProvider.verify(FMSigProvider.java:329)
>
> at
> com.sun.identity.saml2.protocol.impl.RequestAbstractImpl.isSignatureValid(RequestAbstractImpl.java:313)
>
> at
> org.forgerock.openam.saml2.UtilProxySAMLAuthenticator.authenticate(UtilProxySAMLAuthenticator.java:182)
>
> at
> com.sun.identity.saml2.profile.IDPSSOFederate.process(IDPSSOFederate.java:233)
>
> at
> com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:142)
>
> at
> com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:102)
>
> at
> org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFederate_jsp.java:158)
>
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
>
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
>
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
>
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
> at
> org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
> at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:106)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
> at
> org.forgerock.openam.audit.context.AuditContextFilter.doFilter(AuditContextFilter.java:51)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
>
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
>
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
>
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
>
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)
>
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
>
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
>
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>
> at java.lang.Thread.run(Thread.java:745)
>
> Caused by: org.apache.xml.security.signature.XMLSignatureException:
> Signature length not correct: got 256 but was expecting 128
>
> Original Exception was java.security.SignatureException: Signature
> length not correct: got 256 but was expecting 128
>
> at
> org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:93)
>
> at
> org.apache.xml.security.algorithms.SignatureAlgorithm.verify(SignatureAlgorithm.java:301)
>
> at
> org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:723)
>
> at
> org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:660)
>
> at
> com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:348)
>
> ... 42 more
>
> Caused by: java.security.SignatureException: Signature length not
> correct: got 256 but was expecting 128
>
> at sun.security.rsa.RSASignature.engineVerify(RSASignature.java:189)
>
> at java.security.Signature$Delegate.engineVerify(Signature.java:1219)
>
> at java.security.Signature.verify(Signature.java:652)
>
> at
> org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:91)
>
> ... 46 more
>
>
>
> Could it possibly be a Java version error? Any help will be appreciated.
>
>
>
> Thanks
>
>
>
> ------------------------------------------------------------------------
>
> *From:*[hidden email] <[hidden email]> on
> behalf of Nicolas Seigneur <[hidden email]>
> *Sent:* Wednesday, May 25, 2016 7:20 PM
> *To:* Users
> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>
>
>
> I suspect the SP is configured with 256 Key Size while the the OpenAM is
> configured with the default 128 Key Size.
>
>
>
> In Federation Tab, click on your IDP and look for Key Size, set it to
> 256, restart OpenAM and I believe this would fix this issue.
>
>
>
> Nicolas Seigneur
>
> Indigo Consulting Canada
>
>
>
> On Wed, May 25, 2016 at 9:32 AM, Eivind Mikkelsen <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> If you don't have a lot of traffic on your OpenAM IdP currently, I
> suggest that you enable message level debug logging for the Federation
> module using Debug.jsp (no restart required), retest authentication and
> check the SignatureMethod and DigestMethod Algorithm for the logged
> AuthnRequest in the Federation log.
>
>
>
> Best regards
>
> Eivind Mikkelsen
>
>
>
> On Wed, May 25, 2016 at 12:15 PM, Anish Narang <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     I have setup OpenAM Idp and registered a Python djangosaml SP in the
>     same circle of trust with their metadata. On sending the
>     authentication request from the SP, I end up with an error ‘Invalid
>     signature in Request’. And this is what the openam debug logs show :
>
>     WARNING: FMSigProvider.isValidSignature: XML signature validation
>     failed due to
>     org.apache.xml.security.signature.XMLSignatureException: Signature
>     length not correct: got 256 but was expecting 128
>     Original Exception was java.security.SignatureException: Signature
>     length not correct: got 256 but was expecting 128
>     libSAML2:05/25/2016 11:41:17:265 AM IST:
>     Thread[http-bio-8080-exec-10,5,main]:
>     TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
>     ERROR: UtilProxySAMLAuthenticator.authenticate: authn request
>     verification failed.
>     com.sun.identity.saml2.common.SAML2Exception: Signature length not
>     correct: got 256 but was expecting 128
>
>     What could be the cause for this and how do I fix it?
>
>     Thanks
>
>
>
>
>
>     _______________________________________________
>     Visit the OpenAM forum at
>     https://forgerock.org/forum/fr-projects/openam/
>     OpenAM mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.forgerock.org/mailman/listinfo/openam
>
>
>
>
> _______________________________________________
> Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
> OpenAM mailing list
> [hidden email] <mailto:[hidden email]>
> https://lists.forgerock.org/mailman/listinfo/openam
>
>
>
>
>
> --
>
> -------------------------------------------------
>
> Nicolas Seigneur
> Indigo Technologies Canada, Inc.
> mobile: +1.514.965.4890
>
> [hidden email] <mailto:[hidden email]>
> www.indigoconsulting.ca <http://www.indigoconsulting.ca/>
>
>
>
> ------------------------------------------------------------------------
> Avast logo <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
>
> ------------------------------------------------------------------------
> Avast logo
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
>
>
>
> _______________________________________________
> Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
> OpenAM mailing list
> [hidden email]
> https://lists.forgerock.org/mailman/listinfo/openam
>


--
Painstaking Minds
IT-Consulting Bernhard Thalmayr
Herxheimer Str. 5, 83620 Vagen (Munich area), Germany
Tel: +49 (0)8062 7769174
Mobile: +49 (0)176 55060699

[hidden email] - Solution Architect
http://www.xing.com/profile/Bernhard_Thalmayr
http://de.linkedin.com/in/bernhardthalmayr

This e-mail may contain confidential and/or privileged information.If
you are not the intended recipient (or have received this email in
error) please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenAM integration with Python djangosaml

Bernhard Thalmayr
Set debug level to message, flush all OpenAM debug logs and restart
OpenAM deployment container.

The keystore is currently loaded statically.

Check OpenAM debug logs for related issuses.

-Bernhard



Am 26/05/16 um 17:38 schrieb Anish Narang:

> Yes you're right. The SAML response is being created and the error is caused while signing.
>
> The keystore is accessible using the default settings on the CLI so Im not sure whats going wrong. How do I fix the issue?
>
> Thanks
>
>
> ________________________________________
> From: [hidden email] <[hidden email]> on behalf of Bernhard Thalmayr <[hidden email]>
> Sent: Thursday, May 26, 2016 6:26 PM
> To: [hidden email]
> Subject: Re: [OpenAM] OpenAM integration with Python djangosaml
>
> Most likely OpenAM could not initialize the SAML keystore.
>
> The private key is needed if you perform response / assertion signing at
> the IdP.
>
> -Bernhard
>
> Am 26/05/16 um 10:02 schrieb Anish Narang:
>> Thanks for the information.
>>
>>
>> The previous error of Null input was produced when requests signed
>> setting was disabled in the IdP as well as the metadata of the SP. Does
>> that mean I have gone wrong some where else? I cant quite understand the
>> error of private key being null.
>>
>>
>> Regrds,
>> Anish
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* [hidden email] <[hidden email]> on
>> behalf of Bernie Jones <[hidden email]>
>> *Sent:* Thursday, May 26, 2016 1:19 PM
>> *To:* 'Users'
>> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>>
>>
>> The requirement for *requests* from the SP to be signed is a
>> configuration setting in the IDP – if it’s set in the IDP then the SP
>> must sign and include the public key in the metadata for the IDP to
>> validate.
>>
>> (So leaving the requirement set in the IDP and disabling signing in the
>> SP would cause the problem seen).
>>
>>
>>
>> The requirement for *assertions* from the IDP to be signed is likewise a
>> configuration setting in the SP – if it’s set then the IDP must sign
>> assertions and include the public key in its metadata for the SP to
>> validate.
>>
>>
>>
>> So, my thought was just  that if you don’t actually need requests to be
>> signed then you could disable this requirement in the IDP. That wouldn’t
>> actually result in a fix for the original 128/256 problem but rather
>> work around it if acceptable security-wise.
>>
>>
>>
>> I would anticipate however that you would still want your assertions
>> from the IDP signed so would still need to have compatible hashing
>> algorithms supported on both sides to support that.
>>
>>
>>
>> Hope that helps.
>>
>>
>>
>> Regards,
>>
>> Bernie
>>
>>
>>
>> *From:*[hidden email]
>> [mailto:[hidden email]] *On Behalf Of *Anish Na
>> *Sent:* 26 May 2016 08:20
>> *To:* Users
>> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>>
>>
>>
>> I re imported the metadata and also restarted Tomcat and OpenAM.
>>
>>
>>
>> Once I set the AuthenticationRequestsSigned to false in the SP metadata,
>> I get the following error :
>>
>>
>>
>> ERROR: Cannot recover key
>>
>> libSAML2:05/26/2016 12:45:07:547 PM IST:
>> Thread[http-bio-8080-exec-4,5,main]:
>> TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]
>>
>> ERROR: FMSigProvider.sign: Either input xml string or id value or
>> private key is null.
>>
>> libSAML2:05/26/2016 12:45:07:547 PM IST:
>> Thread[http-bio-8080-exec-4,5,main]:
>> TransactionId[6a31ed7c-1a02-42f3-b547-cc64695d053d-1330]
>>
>> ERROR: IDPSSOFederate.generateAssertionResponseUnable to do sso or
>> federation.
>>
>> com.sun.identity.saml2.common.SAML2Exception: Null input.
>>
>>
>>
>> Is that the right  way to do it?
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:*[hidden email] <[hidden email]> on
>> behalf of Bernie Jones <[hidden email]>
>> *Sent:* Thursday, May 26, 2016 11:41 AM
>> *To:* Users
>> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>>
>>
>>
>> Do you just need to re-export and import your metadata after the change...?
>>
>> (Also, do you actually need request signing?)
>>
>>
>>
>> Regards,
>>
>> Bernie
>>
>>
>>
>>
>> -------- Original message --------
>> >From Anish Narang <[hidden email]>
>> Date: 26/05/2016 06:54 (GMT+00:00)
>> To Users <[hidden email]>
>> Subject Re: [OpenAM] OpenAM integration with Python djangosaml
>>
>> Thanks for the suggestion. I changed the key size to 256 and the
>> encryption algorithm to http://www.w3.org/2001/04/xmlenc#aes256-cbc on
>> the IdP. However, I still end up with the same error. Here is a complete
>> description of it as given by the Federation debug logs of OpenAM :
>>
>>
>>
>> FMSigProvider.verify: The cert contained in the document is trusted
>>
>> libSAML2:05/26/2016 10:57:07:435 AM IST:
>> Thread[http-bio-8080-exec-10,5,main]:
>> TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
>>
>> validateCertificate :  CRL check is not configured. Just return it is good.
>>
>> libSAML2:05/26/2016 10:57:07:436 AM IST:
>> Thread[http-bio-8080-exec-10,5,main]:
>> TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
>>
>> WARNING: FMSigProvider.isValidSignature: XML signature validation failed
>> due to org.apache.xml.security.signature.XMLSignatureException:
>> Signature length not correct: got 256 but was expecting 128
>>
>> Original Exception was java.security.SignatureException: Signature
>> length not correct: got 256 but was expecting 128
>>
>> libSAML2:05/26/2016 10:57:07:436 AM IST:
>> Thread[http-bio-8080-exec-10,5,main]:
>> TransactionId[1dcdf4e2-671c-4d13-8213-826b7234337d-731]
>>
>> ERROR: UtilProxySAMLAuthenticator.authenticate: authn request
>> verification failed.
>>
>> com.sun.identity.saml2.common.SAML2Exception: Signature length not
>> correct: got 256 but was expecting 128
>>
>> at
>> com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:360)
>>
>> at
>> com.sun.identity.saml2.xmlsig.FMSigProvider.verify(FMSigProvider.java:329)
>>
>> at
>> com.sun.identity.saml2.protocol.impl.RequestAbstractImpl.isSignatureValid(RequestAbstractImpl.java:313)
>>
>> at
>> org.forgerock.openam.saml2.UtilProxySAMLAuthenticator.authenticate(UtilProxySAMLAuthenticator.java:182)
>>
>> at
>> com.sun.identity.saml2.profile.IDPSSOFederate.process(IDPSSOFederate.java:233)
>>
>> at
>> com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:142)
>>
>> at
>> com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOFederate.java:102)
>>
>> at
>> org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFederate_jsp.java:158)
>>
>> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
>>
>> at
>> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
>>
>> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
>>
>> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>>
>> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>>
>> at
>> org.forgerock.openam.validation.ResponseValidationFilter.doFilter(ResponseValidationFilter.java:44)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>>
>> at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:106)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>>
>> at
>> org.forgerock.openam.audit.context.AuditContextFilter.doFilter(AuditContextFilter.java:51)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
>>
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
>>
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
>>
>> at
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
>>
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
>>
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
>>
>> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
>>
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
>>
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)
>>
>> at
>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
>>
>> at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
>>
>> at
>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>
>> at
>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>>
>> at java.lang.Thread.run(Thread.java:745)
>>
>> Caused by: org.apache.xml.security.signature.XMLSignatureException:
>> Signature length not correct: got 256 but was expecting 128
>>
>> Original Exception was java.security.SignatureException: Signature
>> length not correct: got 256 but was expecting 128
>>
>> at
>> org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:93)
>>
>> at
>> org.apache.xml.security.algorithms.SignatureAlgorithm.verify(SignatureAlgorithm.java:301)
>>
>> at
>> org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:723)
>>
>> at
>> org.apache.xml.security.signature.XMLSignature.checkSignatureValue(XMLSignature.java:660)
>>
>> at
>> com.sun.identity.saml2.xmlsig.FMSigProvider.isValidSignature(FMSigProvider.java:348)
>>
>> ... 42 more
>>
>> Caused by: java.security.SignatureException: Signature length not
>> correct: got 256 but was expecting 128
>>
>> at sun.security.rsa.RSASignature.engineVerify(RSASignature.java:189)
>>
>> at java.security.Signature$Delegate.engineVerify(Signature.java:1219)
>>
>> at java.security.Signature.verify(Signature.java:652)
>>
>> at
>> org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineVerify(SignatureBaseRSA.java:91)
>>
>> ... 46 more
>>
>>
>>
>> Could it possibly be a Java version error? Any help will be appreciated.
>>
>>
>>
>> Thanks
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:*[hidden email] <[hidden email]> on
>> behalf of Nicolas Seigneur <[hidden email]>
>> *Sent:* Wednesday, May 25, 2016 7:20 PM
>> *To:* Users
>> *Subject:* Re: [OpenAM] OpenAM integration with Python djangosaml
>>
>>
>>
>> I suspect the SP is configured with 256 Key Size while the the OpenAM is
>> configured with the default 128 Key Size.
>>
>>
>>
>> In Federation Tab, click on your IDP and look for Key Size, set it to
>> 256, restart OpenAM and I believe this would fix this issue.
>>
>>
>>
>> Nicolas Seigneur
>>
>> Indigo Consulting Canada
>>
>>
>>
>> On Wed, May 25, 2016 at 9:32 AM, Eivind Mikkelsen <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> If you don't have a lot of traffic on your OpenAM IdP currently, I
>> suggest that you enable message level debug logging for the Federation
>> module using Debug.jsp (no restart required), retest authentication and
>> check the SignatureMethod and DigestMethod Algorithm for the logged
>> AuthnRequest in the Federation log.
>>
>>
>>
>> Best regards
>>
>> Eivind Mikkelsen
>>
>>
>>
>> On Wed, May 25, 2016 at 12:15 PM, Anish Narang <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Hi,
>>
>>     I have setup OpenAM Idp and registered a Python djangosaml SP in the
>>     same circle of trust with their metadata. On sending the
>>     authentication request from the SP, I end up with an error ‘Invalid
>>     signature in Request’. And this is what the openam debug logs show :
>>
>>     WARNING: FMSigProvider.isValidSignature: XML signature validation
>>     failed due to
>>     org.apache.xml.security.signature.XMLSignatureException: Signature
>>     length not correct: got 256 but was expecting 128
>>     Original Exception was java.security.SignatureException: Signature
>>     length not correct: got 256 but was expecting 128
>>     libSAML2:05/25/2016 11:41:17:265 AM IST:
>>     Thread[http-bio-8080-exec-10,5,main]:
>>     TransactionId[1b6bcc0f-5df1-4c8a-aaa9-bed7d7c9729a-1699]
>>     ERROR: UtilProxySAMLAuthenticator.authenticate: authn request
>>     verification failed.
>>     com.sun.identity.saml2.common.SAML2Exception: Signature length not
>>     correct: got 256 but was expecting 128
>>
>>     What could be the cause for this and how do I fix it?
>>
>>     Thanks
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     Visit the OpenAM forum at
>>     https://forgerock.org/forum/fr-projects/openam/
>>     OpenAM mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.forgerock.org/mailman/listinfo/openam
>>
>>
>>
>>
>> _______________________________________________
>> Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
>> OpenAM mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://lists.forgerock.org/mailman/listinfo/openam
>>
>>
>>
>>
>>
>> --
>>
>> -------------------------------------------------
>>
>> Nicolas Seigneur
>> Indigo Technologies Canada, Inc.
>> mobile: +1.514.965.4890
>>
>> [hidden email] <mailto:[hidden email]>
>> www.indigoconsulting.ca <http://www.indigoconsulting.ca/>
>>
>>
>>
>> ------------------------------------------------------------------------
>> Avast logo <https://www.avast.com/antivirus>
>>
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.com <https://www.avast.com/antivirus>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>> Avast logo
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>>
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
>> OpenAM mailing list
>> [hidden email]
>> https://lists.forgerock.org/mailman/listinfo/openam
>>
>
>
> --
> Painstaking Minds
> IT-Consulting Bernhard Thalmayr
> Herxheimer Str. 5, 83620 Vagen (Munich area), Germany
> Tel: +49 (0)8062 7769174
> Mobile: +49 (0)176 55060699
>
> [hidden email] - Solution Architect
> http://www.xing.com/profile/Bernhard_Thalmayr
> http://de.linkedin.com/in/bernhardthalmayr
>
> This e-mail may contain confidential and/or privileged information.If
> you are not the intended recipient (or have received this email in
> error) please notify the sender immediately and delete this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
> _______________________________________________
> Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
> OpenAM mailing list
> [hidden email]
> https://lists.forgerock.org/mailman/listinfo/openam
> _______________________________________________
> Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
> OpenAM mailing list
> [hidden email]
> https://lists.forgerock.org/mailman/listinfo/openam
>


--
Painstaking Minds
IT-Consulting Bernhard Thalmayr
Herxheimer Str. 5, 83620 Vagen (Munich area), Germany
Tel: +49 (0)8062 7769174
Mobile: +49 (0)176 55060699

[hidden email] - Solution Architect
http://www.xing.com/profile/Bernhard_Thalmayr
http://de.linkedin.com/in/bernhardthalmayr

This e-mail may contain confidential and/or privileged information.If
you are not the intended recipient (or have received this email in
error) please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
_______________________________________________
Visit the OpenAM forum at https://forgerock.org/forum/fr-projects/openam/
OpenAM mailing list
[hidden email]
https://lists.forgerock.org/mailman/listinfo/openam
Loading...