Jeg benytter OIOSAML 9818 og har indtil for nylig kørt på min lokale Weblogic og lavet en mapning i min hosts fil, så at mydomain.dk pegede på min lokale Weblogic instans. Jeg har sat keystore op som jeg forventer det skulle sættes op på mydomain.dk og det virker fint lokalt. Dvs. NemLogin diregerer min browser tilbage til mydomain.dk og så går min browser til min lokale weblogic (127.0.0.1).
Jeg kopiere hele opsætningen over på det eksterne testmiljø (herunder også certificate/keystore). Jeg bliver ledt til NemLog-in som forventet, men når jeg bliver stillet tilbage til min test-server, så får jeg fejlen vist på vedhæftede screenshot:
Request failed: Unable to validate SAML message!
Nogen der kan hjælpe? Jeg har forsøgt at opgradere til 21188, men det er ikke lykkes mig. (Jeg har allerede henvendt mig i dette forum angående dette.)
Stacktrace fra log-filen:
[2016-01-08 14:51:59,483] [ERROR] [[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] [OIOSAML_AUDIT_LOGGER] Dispatch:SAMLAssertionConsumer <-- 172.30.124.4 KjTnWP2CTZn4X8kQWKGL3hMtnzG3KYvMmRbL25R1yGMKSdcvvytd!-1834801224!1452261090907 '' '' 'org.opensaml.xml.encryption.DecryptionException: Failed to decrypt EncryptedData'dk.itst.oiosaml.sp.model.validation.ValidationException: org.opensaml.xml.encryption.DecryptionException: Failed to decrypt EncryptedData at dk.itst.oiosaml.sp.model.OIOEncryptedAssertion.decryptAssertion(OIOEncryptedAssertion.java:75) at dk.itst.oiosaml.sp.model.OIOResponse.decryptAssertion(OIOResponse.java:139) at dk.itst.oiosaml.sp.service.SAMLAssertionConsumerHandler.handleSAMLResponse(SAMLAssertionConsumerHandler.java:130) at dk.itst.oiosaml.sp.service.SAMLAssertionConsumerHandler.handlePost(SAMLAssertionConsumerHandler.java:92) at dk.itst.oiosaml.sp.service.DispatcherServlet.doPost(DispatcherServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119) at java.security.AccessController.doPrivileged(Native Method) at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315) at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442) at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103) at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171) at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:139) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3730) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3696) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2273) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1490) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256) at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)Caused by: org.opensaml.xml.encryption.DecryptionException: Failed to decrypt EncryptedData at org.opensaml.xml.encryption.Decrypter.decryptDataToDOM(Decrypter.java:523) at org.opensaml.xml.encryption.Decrypter.decryptDataToList(Decrypter.java:439) at org.opensaml.xml.encryption.Decrypter.decryptData(Decrypter.java:400) at org.opensaml.saml2.encryption.Decrypter.decryptData(Decrypter.java:141) at org.opensaml.saml2.encryption.Decrypter.decrypt(Decrypter.java:69) at dk.itst.oiosaml.sp.model.OIOEncryptedAssertion.decryptAssertion(OIOEncryptedAssertion.java:68) ... 32 more
It turned out that this was simply due to Java Security Policy. Using the "Unlimited strengh" policy solved the problem.
Hej oiosaml team,
Vi har en webapplikation som kører på weblogic 10.3. Den kører fint i vores interne netværk med en URL http://lokal-app.itu.dk:8099. Men den skal også virke udefra. Derfor prøver vi at bruge en proxy, med en offentlig URL: https://offentlig-app.itu.dk/.
Naturligvis har vi opdateret vores tjenestes-metadata / service provider / SP og vores dets tilsvarende metadata på vores ID-provider / IDP, som bruger på simpleSAMLphp.
Når man prøver at komme på applikationen hjemmefra og logger på https:// offentlig-app.itu.dk/, får man vores IDPs login side, og man kan logge på den normalt.
Problemet sker efter man er logget på.
Vores SP kan ikke genkende forespørgslen, og den tror, at det er en ny frisk forespørgsel, og dermed sender det tilbage til IDP'en.
IDP'en kan se at personen allerede er logget på, og sender ham/hende tilbage til proxy'en og derfra tilbage til SP.
De forsætter indtil man lukke browseren.
Jeg har tjekket http trafikken mellem SP’en og IDP’en, ved at bruge FireFox plugin: SAMLtracer, som viser identiske SAML beskeder, undtagen session ID.
Jeg har tjekket oiosaml-sp.log, og applikations log filen for en fejl, uden held. Helt ser normalt ud.
Er der nogen kan hjælpe os med en hint, om hvad kan være oversagen til denne opførsel?
På forhånd tak
Thabet
Hej Thabet
Den opførsel du beskriver kan skyldes at jeres SP ikke får skrevet login billetten eller at cookie'n bliver skrevet med forkert domæne. I så fald vil browseren ikke præsentere login-billetten.
Efter login redirect'es til den oprindelige side som login blev startet fra. Hvis der nu stadig ikke er logget ind får du en tur til omkring IdP'en.
Prøv at se med Fiddler eller lignende hvilke cookies der bliver skrevet med hvilke domæner stier. Vær særlig opmærksom på om disse cookies bliver sendt tilbage til serveren fra browseren.
Håber det hjælper dig videre
Uffe
Hej Uffe,
Tak for svaret.
Problemet var på vores proxyserver opsætning i (ProxyPass), (ProxyPassReverse) og URL- Rewrite regler (RewriteRule).
Det er lidt svært at beskrive løsningen i detaljer, men det virker nu.
Tak for hjælpen.
VH
Dear oiosaml-java team,
I am not sure if this is the right place to ask such a question, but I will give a try. Otherwise please direct me to the right forum.
Have anyone tried to use oiosaml.java-9918 on weblogic v.10.3 or any version of weblogic?
I tried to deploy the demo and I got (java.lang.IncompatibleClassChangeError) exception. I guess that it is an error related to java version. Any ideas suggestions will be very appreciated ?
Best regards
Hi Thabet
I don't have the answer to your question, I just wanted to make sure, that you a aware that a newer version of oiosaml.java exists: http://digitaliser.dk/resource/2530598 (version 11330)
/m
Hi,
We have been using OIOSAML.java 9918 as SP and it has been working great.
I have been using IdP configured to sign assertions and everything was working fine. Recently I was playing with the IdP configuration and I changed it to sign responses as well. That too worked fine with OIOSAML.java SP.
However, when I changed the IdP cofinguration to encryptAssertions (in addition to sign responses and sign assertions), I get the following exception on SP in oiosaml-sp.log :
[2013-04-26 15:53:12,896] [WARN ] [http-8080-1] [dk.itst.oiosaml.sp.model.OIOSamlObject] The signature does not meet the requirements indicated by the SAML profile of the XML signatureorg.opensaml.xml.validation.ValidationException: SignableSAMLObject does not have a cached DOM Element. at org.opensaml.security.SAMLSignatureProfileValidator.validateReferenceURI(SAMLSignatureProfileValidator.java:146) at org.opensaml.security.SAMLSignatureProfileValidator.validateSignatureImpl(SAMLSignatureProfileValidator.java:84) at org.opensaml.security.SAMLSignatureProfileValidator.validate(SAMLSignatureProfileValidator.java:56) at dk.itst.oiosaml.sp.model.OIOSamlObject.verifySignature(OIOSamlObject.java:180) at dk.itst.oiosaml.sp.model.OIOResponse.validateResponse(OIOResponse.java:102) at dk.itst.oiosaml.sp.service.SAMLAssertionConsumerHandler.handleSAMLResponse(SAMLAssertionConsumerHandler.java:131) at dk.itst.oiosaml.sp.service.SAMLAssertionConsumerHandler.handlePost(SAMLAssertionConsumerHandler.java:92) at dk.itst.oiosaml.sp.service.DispatcherServlet.doPost(DispatcherServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at dk.itst.oiosaml.sp.service.SPFilter.doFilter(SPFilter.java:163) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Unknown Source)[2013-04-26 15:53:12,896] [ERROR] [http-8080-1] [dk.itst.oiosaml.sp.service.DispatcherServlet] Unable to validate Responsedk.itst.oiosaml.sp.model.validation.ValidationException: The response is not signed correctly at dk.itst.oiosaml.sp.model.OIOResponse.validateResponse(OIOResponse.java:107) at dk.itst.oiosaml.sp.service.SAMLAssertionConsumerHandler.handleSAMLResponse(SAMLAssertionConsumerHandler.java:131) at dk.itst.oiosaml.sp.service.SAMLAssertionConsumerHandler.handlePost(SAMLAssertionConsumerHandler.java:92) at dk.itst.oiosaml.sp.service.DispatcherServlet.doPost(DispatcherServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at dk.itst.oiosaml.sp.service.SPFilter.doFilter(SPFilter.java:163) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
The exception in oiosaml-sp-auit.log is
[ERROR] [http-8080-1] [OIOSAML_AUDIT_LOGGER] Dispatch:SAMLAssertionConsumer <-- 134.177.229.187 1C2668EE9397D73F90D490D0F14DD42B '' '' 'The response is not signed correctly'dk.itst.oiosaml.sp.model.validation.ValidationException: The response is not signed correctly at dk.itst.oiosaml.sp.model.OIOResponse.validateResponse(OIOResponse.java:107) at dk.itst.oiosaml.sp.service.SAMLAssertionConsumerHandler.handleSAMLResponse(SAMLAssertionConsumerHandler.java:131) at dk.itst.oiosaml.sp.service.SAMLAssertionConsumerHandler.handlePost(SAMLAssertionConsumerHandler.java:92) at dk.itst.oiosaml.sp.service.DispatcherServlet.doPost(DispatcherServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
I experimented with different settings on IdP and what I found out is that following two are the only combinations that give trouble:
- Response signed, Assertion signed, Assertions encrypted
- Response signed, Assertion not signed, Assertions encrypted.
Just to verify if it was any issue with processing signed reponses, I tried this setting and it works fine.
- Response signed, Assertion not signed, No Encryption
So processing of signed response in itself is not an issue, but combined with encrypted assertion, it seems to be causing problems. Any idea, how this can be resolved.
By the way, while going through the code, I saw a test class (test/dk/itst/oiosaml/sp/model/OIOResponseTest.java) which mentions a similar issue with opensaml 2.5.1 jar. But there is no fix mentioned there.
Will appreciate any help.
Thanks,
Madhavi
Hej Madhavi
Thank you for you're feedback. I dont really have an answer for you, except that OIOSAML first is a toolkit we have created to support the implementation of our OIOSAML profile, and second a general purpose SAML toolkit.
I does look like it fails in the part that relies on OpenSAML where we a currently using 2.5.1. I've just had a quick look at the release note for the most current (2.6.0 - See below) and does not seem like this have been adressed yet.
You have the option to implement your own Assertion Validator, as described in configuration:
oiosaml-sp.assertion.validator: FQCN of a class which implements dk.itst.oiosaml.sp.model.validation.AssertionValidator. This class is then used to perform validation of received assertions. See developer's guide for more information.
Best regardsBrian Nielsen
Changes in Release 2.6.0=============================================[JOST-135] - Opensaml prunes empty xml namespaces, that are required for correct encryption [JOST-162] - Globally enabling schema validation breaks the Signature metadata filter [JOST-169] - Update Velocity Dependency[JOST-183] - AbstractReloadingMetadataProvider code for maxRefreshDelay doesn't match documentation[JOST-184] - It would be nice if ESAPI.encodeForURL could be made to work[JOST-185] - Defaultbootstrap does not initialize the providers from the WS-Trust and WS-Policy schemas in openws[JOST-187] - Velocity initialization code uses an invalid key for the configuration properties set[JOST-188] - DefaultBootstrap is unnecessarily calling Velocity singleton initialization[JOST-190] - Backport some bugfixes from OpenSAML3[JOST-191] - Merge back misc XACML fixes from OpenSAML3[JOST-192] - org.opensaml.saml2.metadata.provider.SignatureValidationFilter => java.lang.UnsupportedOperationException[JOST-193] - Make the implementation of custom bootstrap code easier, without relying on private data from DefaultBootstrap[JOST-194] - org.opensaml.ESAPISecurityConfig should use singleton pattern like the default ESAPI reference class[JOST-195] - Use system property-based override for our custom ESAPI config rather than ESAPI locator class call [JOST-196] - On MetadataProviderCredentialResolver, expose the MetadataProvider used to construct the resolver[JOST-197] - XML providers for Async Logout extensions[JOST-198] - Configuration files for XMLObject providers often missing Type registrations[JOST-199] - SAML SOAP encoders should use the supplied outbound SOAP Envelope from the message context, if it exists [JOST-200] - Reduce memory usage of unit tests[JOST-201] - SAML1 and 2 base message encoders have incorrect selection logic in getEndpointURL()[JOST-203] - Head/body template injection for SAML binding templates[JOST-205] - MetadataProvider doesn't report error during refresh if the metadata file doesn't exist any more[JOST-206] - Setting failFastInitialization=false has no effect[JOST-207] - FilesystemMetadataProvider fetchMetadata() does not work correctly if file last modified time is older than getLastRefresh() in some cases [JOST-208] - FileBackedHTTPMetadataProvider constructor doesn't behave correctly vis-a-vis fail-fast setting if the backing file path has problems [JOST-209] - Add tests for fail-fast in HTTPMetadataProvider
Changes in Release 2.5.3=============================================[JOST-176] - SubjectConfirmationUnmarshaller processChildElement misplaces KeyInfo[JOST-179] - FileBackedHTTPMetadataProvider does not properly release HTTP connections[JOST-180] - Update dependencies[JOST-181] - Bug in marshalling an XACML Policy AttributeDesignatorType[JOST-182] - Clean up maven assembly description
Changes in Release 2.5.2=============================================[JOST-160] - Not all times in logging normalized to Zulu[JOST-163] - No way to stop AbstractReloadingMetadataProvider threads[JOST-164] - MetadataProvider minRefreshDelay cannot be set greater than 4 hours[JOST-165] - Update 3rd party runtime library dependencies[JOST-171] - org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider:246 missing param in logging statement[JOST-173] - Wrong Treatment of ResponseLocation and Location in Metadata[JOST-174] - ChainingMetadataProvider calls clear() on unmodifiable list
Hi Brian,
Thanks for the suggestion. I will look into that.
Best,
### I figure out the cause of the problem. It still exists in oiosaml.java-21188. It is caused by an unintended interaction between: (1) OIOResponse.decryptAssertion (2) org.opensaml.security.SAMLSignatureProfileValidator.validateReferenceURI (3) DOM cache management in org.opensaml.xml.util.XMLObjectChildrenList OIOResponse.decryptAssertion:public void decryptAssertion(Credential credential, boolean allowUnencrypted) { if (response.getEncryptedAssertions().size() > 0) { OIOEncryptedAssertion enc = new OIOEncryptedAssertion(response.getEncryptedAssertions().get(0)); this.assertion = enc.decryptAssertion(credential); response.getAssertions().add(assertion.getAssertion()); } else { if (!allowUnencrypted && !response.getAssertions().isEmpty()) { throw new ValidationException("Assertion is not encrypted"); } }} the line: response.getAssertions().add(assertion.getAssertion()); ultimately leads to code in org.opensaml.xml.util.XMLObjectChildrenList.add (...) public void add(int index, ElementType element) throws IllegalArgumentException { if (element == null || elements.contains(element)) { return; } setParent(element); parent.getIDIndex().registerIDMappings(element.getIDIndex()); modCount++; elements.add(index, element); } the setParent (element) does: protected void setParent(ElementType element) throws IllegalArgumentException { XMLObject elemParent = element.getParent(); if (elemParent != null && elemParent != parent) { throw new IllegalArgumentException(element.getElementQName() + " is already the child of another XMLObject and may not be inserted in to this list"); } element.setParent(parent); element.releaseParentDOM(true); } the line: element.releaseParentDOM(true); sets the cached DOMs of all the parent, i.e. the saml response, to null Then when: org.opensaml.security.SAMLSignatureProfileValidator. validateReferenceURI tries to validate the reference in the assertion against the top level ID on the saml response using the DOM cache it crashes. if (expected == null) { log.error("SignableSAMLObject does not have a cached DOM Element."); throw new ValidationException("SignableSAMLObject does not have a cached DOM Element."); } Now, it's hard to figure out where the fix truly should be made. ValidateReference is makingassumptions about cached DOM. It could just as easily get the ID of the response with String responseID = ((ResponseImpl) signableObject).getID (); then just check of the responseID.equals (uriID) and skip all the DOM based paranoid checks.
The problem is with OIOSAML and not with OpenSAML.The real problem is hack in OIOEncryptedAssertion line 72 assertion = (Assertion) SAMLUtil.unmarshallElementFromString(res.toXML());
Does OIOSAML.java support ECP profile? It does not look like, but just want to confirm.
Also, if the ECP support is not present currently, is there any plan of adding it in the near future?
Hi Madhavi
To be honest I've never really looked into Enhanced Client and Proxy (ECP) Profile, but I can say that it's not part of our (OIO)SAML-profile and hence not a requirement we've had for our OIOSAML-toolkits. I can't really say how much, if any, the toolkits can help you in implementing the proxy (i presume?).