Re: OpenAM Digest, Vol 67, Issue 23

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

Re: OpenAM Digest, Vol 67, Issue 23

Fetigue Gbane
Hi folks I am trying to setup OpenAM via OAuth 2.0 provider but everything that i have trying to didn't workout . by the way I have openAM 13 already configured now. I have tried to connected openAM with LDAP and i am able to see all my LDAP users on the openAM subject.Now I tried to redirect the API URI in openAM by having all the users authentified themselves before access the API. is anybody help me ?  because I am confuse about the process I am a new hobbies and any help or step by step guide line  are welcome .


Thanks 

Fetigue Gbane

On Sun, May 29, 2016 at 3:00 PM, <[hidden email]> wrote:
Send OpenAM mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.forgerock.org/mailman/listinfo/openam
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenAM digest..."


Today's Topics:

   1. Re: OpenAM integration with Python djangosaml (Bernhard Thalmayr)


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

Message: 1
Date: Sat, 28 May 2016 21:09:57 +0200
From: Bernhard Thalmayr <[hidden email]>
To: [hidden email]
Subject: Re: [OpenAM] OpenAM integration with Python djangosaml
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

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: <a href="tel:%2B1.514.965.4890" value="+15149654890">+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: <a href="tel:%2B49%20%280%298062%207769174" value="+4980627769174">+49 (0)8062 7769174
> Mobile: <a href="tel:%2B49%20%280%29176%2055060699" value="+4917655060699">+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: <a href="tel:%2B49%20%280%298062%207769174" value="+4980627769174">+49 (0)8062 7769174
Mobile: <a href="tel:%2B49%20%280%29176%2055060699" value="+4917655060699">+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


End of OpenAM Digest, Vol 67, Issue 23
**************************************


_______________________________________________
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 Digest, Vol 67, Issue 23

Bernhard Thalmayr
Have you followed the docs? If yes, you may tell where you are
struggling. You may also file a doc bug to improve the related sections.

-Bernhard

Am 29/05/16 um 21:27 schrieb Fetigue Gbane:

> Hi folks I am trying to setup OpenAM via OAuth 2.0 provider but
> everything that i have trying to didn't workout . by the way I have
> openAM 13 already configured now. I have tried to connected openAM with
> LDAP and i am able to see all my LDAP users on the openAM subject.Now I
> tried to redirect the API URI in openAM by having all the users
> authentified themselves before access the API. is anybody help me ?
>  because I am confuse about the process I am a new hobbies and any help
> or step by step guide line  are welcome .
>
>
> Thanks
>
> Fetigue Gbane
>
> On Sun, May 29, 2016 at 3:00 PM, <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Send OpenAM mailing list submissions to
>             [hidden email] <mailto:[hidden email]>
>
>     To subscribe or unsubscribe via the World Wide Web, visit
>             https://lists.forgerock.org/mailman/listinfo/openam
>     or, via email, send a message with subject or body 'help' to
>             [hidden email]
>     <mailto:[hidden email]>
>
>     You can reach the person managing the list at
>             [hidden email] <mailto:[hidden email]>
>
>     When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of OpenAM digest..."
>
>
>     Today's Topics:
>
>        1. Re: OpenAM integration with Python djangosaml (Bernhard Thalmayr)
>
>
>     ----------------------------------------------------------------------
>
>     Message: 1
>     Date: Sat, 28 May 2016 21:09:57 +0200
>     From: Bernhard Thalmayr <[hidden email]
>     <mailto:[hidden email]>>
>     To: [hidden email] <mailto:[hidden email]>
>     Subject: Re: [OpenAM] OpenAM integration with Python djangosaml
>     Message-ID: <[hidden email]
>     <mailto:[hidden email]>>
>     Content-Type: text/plain; charset=utf-8
>
>     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]
>     <mailto:[hidden email]> <[hidden email]
>     <mailto:[hidden email]>> on behalf of Bernhard
>     Thalmayr <[hidden email]
>     <mailto:[hidden email]>>
>     > Sent: Thursday, May 26, 2016 6:26 PM
>     > To: [hidden email] <mailto:[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]
>     <mailto:[hidden email]> <[hidden email]
>     <mailto:[hidden email]>> on
>     >> behalf of Bernie Jones <[hidden email]
>     <mailto:[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]>
>     >> [mailto:[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]
>     <mailto:[hidden email]> <[hidden email]
>     <mailto:[hidden email]>> on
>     >> behalf of Bernie Jones <[hidden email]
>     <mailto:[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]
>     <mailto:[hidden email]>>
>     >> Date: 26/05/2016 06:54 (GMT+00:00)
>     >> To Users <[hidden email] <mailto:[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]
>     <mailto:[hidden email]> <[hidden email]
>     <mailto:[hidden email]>> on
>     >> behalf of Nicolas Seigneur <[hidden email]
>     <mailto:[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]>
>     >> <mailto:[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]>
>     >> <mailto:[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]>
>     <mailto:[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]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >> https://lists.forgerock.org/mailman/listinfo/openam
>     >>
>     >>
>     >>
>     >>
>     >>
>     >> --
>     >>
>     >> -------------------------------------------------
>     >>
>     >> Nicolas Seigneur
>     >> Indigo Technologies Canada, Inc.
>     >> mobile: +1.514.965.4890 <tel:%2B1.514.965.4890>
>     >>
>     >> [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >> www.indigoconsulting.ca <http://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 <http://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 <http://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] <mailto:[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 <tel:%2B49%20%280%298062%207769174>
>     > Mobile: +49 (0)176 55060699 <tel:%2B49%20%280%29176%2055060699>
>     >
>     > [hidden email]
>     <mailto:[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] <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
>     >
>
>
>     --
>     Painstaking Minds
>     IT-Consulting Bernhard Thalmayr
>     Herxheimer Str. 5, 83620 Vagen (Munich area), Germany
>     Tel: +49 (0)8062 7769174 <tel:%2B49%20%280%298062%207769174>
>     Mobile: +49 (0)176 55060699 <tel:%2B49%20%280%29176%2055060699>
>
>     [hidden email]
>     <mailto:[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] <mailto:[hidden email]>
>     https://lists.forgerock.org/mailman/listinfo/openam
>
>
>     End of OpenAM Digest, Vol 67, Issue 23
>     **************************************
>
>
>
>
> _______________________________________________
> 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...