Der findes en nyere version af resourcen her

oiosaml.java 2.0.0

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


Maven repository

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



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


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


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

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

Yves Martin

Hi Yves.

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


Improper error handling at configure step

Yves Martin


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:

	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 ?



Minor bug fixes to oiosaml.java 2.0.0 demo configuration

Mac Wendelboe

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


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

Mads Vering

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...

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




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?

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

Hvad er minimum Java runtime for OIOSAML 2.0.0?

OIOSAML 2.0.0 is build against Java 6


Problems with dependencies

Peter Sone Koldkjær

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] ::::::::::::::::::::::::::::::::::::::::::::::
[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


[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..?

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

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




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).

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