Loading…

Tilbage

Info

Der findes en nyere version af resourcen her

oiosaml.java 2.0.0

07-08-2017 13:09:41

Brian Graversen

OIOSAML for Java release 2.0.0 has been made available. This release marks a series of structural changes

We have changed the versioning scheme from [svn-commit-id] to semantic versionering (major.minor.patch), where this is the first, with the version number 2.0.0
We have started using Maven as the build-tool
The binary artifacts are no longer distributed through digitaliser.dk, but as Maven dependencies (read more below)

Code repository

The code is still available through Softwarebørsen SVN, and can be located here

https://svn.softwareborsen.dk/oiosaml.java/oiosaml2/

Maven repository

The binary artifacts are distributed as Maven dependencies, and can be located here

https://mvnrepository.com/artifact/dk.digst/oiosaml2.java/2.0.0

Changelog

This release contains the following changes

improved error messaging in sitations that happens often (revoked certificates, missing strong crypto, etc etc)
updated to use the latest version of the OpenSAML 2.x series
now supports that Identity Providers uses different certificates for signing/encryption
support repeated claimtypes
improved handling of revocation checking
fixed all broken unittests
explicit handling of NETs test-environment with regard to revocation checking
updated demo application with valid certificates

Regression in IdP metadata support after OIOSAML upgrade

Yves Martin

09. januar 2018, 15:38

Hello

I am working on upgrading from oiosaml.java-21204.jar and I faced issue loading my current IdP metadata (from F5 BigIP APM) which does not explicitly declare use="signing" in KeyDescriptor.

I worked around issue adding "use" attribute to XML entity.

My debug session lent me to IdpMetadata:267

if(kd.getUse().equals(UsageType.SIGNING))

I guess key descriptor has to be selected too if "UNSPECIFIED".

May you please confirm this issue and provide improvement for next release ?

Regards
Yves Martin

Log ind for at besvare

Brian Graversen

10. januar 2018, 6:18

Hi Yves.

thanks for the report - I'll add it to the backlog and make sure we have a release soon.

Log ind for at besvare

Improper error handling at configure step

Yves Martin

08. januar 2018, 14:01

Hello

When configuring with "/saml/configure", an error occurs but code to handle error relies on "configuration" to be available. As a result, I receive error page with stack trace:

java.lang.NullPointerException
	at dk.itst.oiosaml.sp.service.DispatcherServlet.handleError(DispatcherServlet.java:288)
	at dk.itst.oiosaml.sp.service.DispatcherServlet.doPost(DispatcherServlet.java:216)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)

May you please report issue so that it may be fixed soon ?

Regards
Yves

Log ind for at besvare

Minor bug fixes to oiosaml.java 2.0.0 demo configuration

Mac Wendelboe

29. november 2017, 14:53

I experienced a few issues with the demo.

Feel free to apply my patch:

Minor bug fixes to oiosaml.java 2.0.0 demo configuration

Log ind for at besvare

Morten Holst Henriksen

26. december 2017, 0:24

Thanks :-)

Log ind for at besvare

OIOSAML.java 2.0.0 complaint with current NemLog-in SHA1?

Can you confirm, that the new OIOSAML.java 2.0.0 is still complaint with current version of NemLog-in and SHA1? So that the upgrade in production does not need to be aligned calender-wise with the shift at your side...

Log ind for at besvare

Brian Graversen

26. oktober 2017, 10:51

It defaults to sha-256, but you can configure it to use sha-1 with this setting

oiosaml-sp.signature.algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1

Log ind for at besvare

Mads Vering

08. december 2017, 7:16

Hi Brian,

I have upgraded OIOSAML to version 2.0.0 in our test environment. Without changing anything at the NemLog-in side, it still worked after the upgrade.

Then, I had our test-environment upgraded to SHA-256. After the upgrade everything still worked. As regards to your post I expected a failure, since I have not yet set the configuration that you mentioned above.

Is a non-failure to be expected in my situation? Can I upgrade production environment and everything will work without the configuration you mention?

Brian Graversen

08. december 2017, 10:23

Hi Mads.

I wouldn't have expected that to work, but one possible reason could be that NemLog-in accepts both SHA-1 and SHA-256 outgoing from the service provider.

When you set your configuration to SHA-256, then your SP will start using SHA-256 as the hash algorithm for the signature for AuthnRequests and the logout requests. OIOSAML will still accept SHA-1 signatures on the responses from NemLog-in, even if it is configured for SHA-256 itself.

So if NemLog-in accepts both SHA-1 and SHA-256 based signatures, then that is likely why it works - I'm pretty sure that NemLog-in will respond with SHA-1 unless they "flip the switch" on their side though.

Probably better to look at the trafic that you are sending back and forth, and check what algorithms that NemLog-in is using, and then ask the NemLog-in support if they expect the same behaviour in production

Minimum Java runtime

Mads Vering

10. oktober 2017, 8:17

Hvad er minimum Java runtime for OIOSAML 2.0.0?

Log ind for at besvare

Brian Graversen

10. oktober 2017, 8:23

OIOSAML 2.0.0 is build against Java 6

Log ind for at besvare

Problems with dependencies

Peter Sone Koldkjær

28. august 2017, 14:43

I have just put the following dependency into our Ivy setup:

<!-- https://mvnrepository.com/artifact/dk.digst/oiosaml2.java -->
<dependency org="dk.digst" name="oiosaml2.java" rev="2.0.0"/>

I get:

[ivy:resolve] ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:resolve] :: UNRESOLVED DEPENDENCIES ::
[ivy:resolve] ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:resolve] :: org.apache.velocity#velocity;1.7: not found
[ivy:resolve] :: commons-configuration#commons-configuration;1.10: not found
[ivy:resolve] ::::::::::::::::::::::::::::::::::::::::::::::

I think I have my resolvers right...

[ivy:resolve] io problem while parsing ivy file: http://central.maven.org/maven2/org/apache/velocity/velocity/1.7/velocity-1.7.pom: Resetting to invalid mark
[ivy:resolve] module not found: org.apache.velocity#velocity;1.7

and

[ivy:resolve] io problem while parsing ivy file: http://central.maven.org/maven2/commons-configuration/commons-configuration/1.10/commons-configuration-1.10.pom: Resetting to invalid mark
[ivy:resolve] module not found: commons-configuration#commons-configuration;1.10

Any ideas..?

Mvh.
Peter Sone Koldkjær, mySupply ApS
Konsulent (NemHandel) for Digitaliseringsstyrelsen

Log ind for at besvare

Brian Graversen

28. august 2017, 16:22

Not sure exactly why you are encountering this issue.

If I try with a plain Maven pom.xml file, with only oiosaml as a dependency, and a clean local maven repository, then all dependencies resolve, and are downloaded. Could you try the same, just to check that the dependencies are resolved?

If I click on the links that your Ivy build fails on, they link to an actual file, so not sure why you cannot find the files.

Both of these seem to work fine when opening them in a browser

http://central.maven.org/maven2/org/apache/velocity/velocity/1.7/velocity-1.7.pom

http://central.maven.org/maven2/commons-configuration/commons-configuration/1.10/commons-configuration-1.10.pom

Perhaps it helps to clean your local repository (not sure if Ivy uses the .m2/repository folder, but if it does, then delete that and try again).

Log ind for at besvare

Peter Sone Koldkjær

28. august 2017, 16:40

Updated Ivy to the latest version 2.4... it did the trick ;-)