The following have been included in this release:
* Readded the option to support self signed certificates by setting oiosaml-sp.crl.period=0.
I've been running oiosaml.java 21188 successfully on Jetty 6 with
Java 7 for a few months now. However, I need to upgrade to Java 8
but unfortunately this causes oiosaml to fail when the application is initiated:
ERROR 12 jan. 15:08:36 [main] dk.itst.oiosaml.logging.LoggerFactory -
Unable to retrieve configurationjava.lang.IllegalStateException:
System not configured at
Has anyone had similar experiences and is oiosaml 21188 known to work
with Java 8?
I've been using oiosaml.java 21188 with Java 8 for some time now,
with no issues. The error seems to suggest a problem with Log4J
configuration. You might want to check up on that. Oiosaml.java logs
everything using Log4J by default.
Webapplication deployed on tomcat 6.0. Log out does not work -
NemLog-in is not getting called upon logout. We do call
"/saml/Logout", which in web.xml points to the
SAMLDispatcherServlet, but this call fails with the error below.
We can log in just fine, which makes me think that certificate has
been set up correctly.
The error we get is this on (oiosaml-sp.log)
[ERROR] [http-9080-15] [dk.itst.oiosaml.sp.service.DispatcherServlet]
Unable to validate Responsejava.lang.IllegalStateException
at com.logica.nemlogin.LogoutServlet.doPost(Unknown Source) at
com.logica.nemlogin.LogoutServlet.doGet(Unknown Source) at
and this in oiosaml-sp-audit.log
[ERROR] [http-9080-15] [OIOSAML_AUDIT_LOGGER] Dispatch:Logout <--
at com.logica.nemlogin.LogoutServlet.doPost(Unknown Source) at
com.logica.nemlogin.LogoutServlet.doGet(Unknown Source) at
We found the problem. We made a HTTP-redirect in the
userLoggedOut-method (in the class implementing the
LogoutAuthenticationHandler interface) and this apparently obstructed
the "OIOSAML-flow" as the OIOSAML caller of our
userLoggedOut-method expected to get back the control upon
userLoggedOut-return. And this apparently does not happen when redirecting.
We have trouble making single-log-out work. We use the newest OIOSAML-21188.
Our applications is an ear-file deployed on a WebLogic 10.3.6. This
ear-file contains two war-files:
When we call logout using the https://sp1.test-nemlog-in.dk/demo/
stub, we are not logged out of our application. We can see in the
logs-files from OIOSAML, that a logout-call from NemLog-in is recieved:
[2016-02-26 15:22:56,092] [INFO ] [[ACTIVE] ExecuteThread: '0' for
queue: 'weblogic.kernel.Default (self-tuning)']
user out via SLO HTTP Redirect: C=DK,O=Ã˜konomistyrelsen //
As far as I understand, the OIOSAML should invalidate the session
upon logout - this is excactly how we log-out when logging out in our
own application. Logging out in our own application works perfectly:
the user is logged out, and the https://sp1.test-nemlog-in.dk/demo/
stub is logged out as well.
In the weblogic-application we have shared the session between the
Any ideas where we should look to solve the issue?
I found a way to solve the problem. I had a look in the OIOSAML source code, and found what I needed in the form of the LogoutAuthenticationHandler. When registering an implementation of this via "oiosaml-sp.authenticationhandler" in "oiosaml-sp.properties" this implementation gets called upon logout.
A question: Why does LogoutAuthenticationHandler extends AuthenticationHandler? This means that I also need to implement
public abstract boolean userAuthenticated(UserAssertion userassertion, HttpServletRequest httpservletrequest, HttpServletResponse httpservletresponse);
which I feel no need for. As far as I can see, just returning "true" should be equivalent to the AuthenticationHandler not being there, so this is what I've done.
I have come to to the point in my implementation of NemLog-in Signing, where I need to validate the response from the NemLog-in Signing Web App properly.
In the Signing Service Interface document, chapter 7, page 17, bullet a) requires for one to validate, that the response has been signed by the VOCES certificate published for the signing service.
My question is about, how this check is to be performed in relation to the content of the returned SignedSignatureProof. I do know how to perform this check for my own generated SignedFingerPrint (using the public key of my SP-function certificate), but how do I get about it, when it comes to the SignedSignatureProof? Shall I check the entire content or a specific part of it? And what about the digest algorithm to use? A piece of pseudo-code would be very much appreciated. Thank you.
Please ignore my question. I was not paying attention to the content
of the SignedFingerPrint delivered from the signing service (thought
is was the samme as in the corresponding request - silly of me).
Bare with me :)
I have problems performing signing verification of a successfull
(satus=OK) response received from the NemLog-in Signing Test Web App.
As opposed to the documentation of how to formulate the request, the
documentation for the response is a bit unclear. On page 10 () it is
stated that the SignedFingerPrint has been constructed as of:
SignedFingerPrint = Base64Encode(SignSha256WithRsa(Utf8Encode(Concat(RequestId,Status,EntityId,PID,CVR,RID,Base64Encode(Utf8Encode(SignedSignatureProof))))))
As the SignedSignatureProof is already Base64 and UTF-8 encoded (in
the response), the last 3 lines doesn't make much sense.
I have downloaded the public-key certificated from:
but I am unable to verify the response. I tried with and without the
suggested double Base64 and UTF-8 encoding, but no luck. As I am
perfectly capable of delivering a signed fingerprint for the request,
i believe my Java-code is OK in that regard.
Please help me out - thank you.
PS: Attached you will find code for the methods I am using for
performing the verification.
I also have another issue regarding how to use the CRLChecker for the
VOCES certificate of the NemLog-in Signing Web App. I have spotted the method:
boolean doOCSPCheck(Configuration conf, Stringentity
Id, Metadata md, X509Certificatecertificate)
of the CRLChecker in OIOSAML-JAVA. It seems odd that this method is
private. Furthermode, it doesn't use the metadata parameter for anything.
Which entityId do I need to invoke this method with, when performing
CRL-check of the VOCES certificate of the signing service app?
How can I customize the periodically performed CRL-check of all of
the other certificates, such that my downloaded Signing service
certificate will be validated as well?
Why does OIOSAML-JAVA not have the concept of "metadata"
for the Signing Web App, as it have for the Idp?
Reagarding troubleshooting your integration with NemLog-in Signing
Service ... you should write to email@example.com. They will know who
to set you in contact with regarding this matter.
OIOSAML is totally unrelated to NemLog-in Signing Service ... but
fell free to cherry pick whatever logic you need in order to comply
with the NemLog-in Signing Service.
Kasper V. Møller
I will do so.
Nevertheless, in my signing-scenario I would very much like to re-use the configuration aspects of OIOSAML, especially the SPMetadata.
I am implementing a SigningFilter (a la SPFilter), but I cannot get it initialized properly using similar logic as implemented in init() of SPFilter.
Furthermore, in our framework we need to make use of multiple instances of SPFilter, more precisely sub-class instances of SPFilter. Is there anything in the SPFilter implementation that wil prevent it from being instantiated multiple times?
The reason for why we need to have multiple instances is, that we need to perform special param-pattern filterings for special url-patterns. We are currently configurering such param-patterns using init-params of our filters in WEB.xml.
In this way a param-pattern will follow the definition in WEB-xml, but the url-patterns for such a filter follows the filter-mapping.
In order to have param-pattern A applied to url-pattern UA, and in order to have param-pattern B applied to url-pattern UB, we need two login-filters, A and B, and two filter-mappings, one for A and one for B.
Is multiple SPFilter instances supported?
As you can see in the link below ... filters are applied in a chain.
SPFilter is only designed to be present in the filter chain one time
during a request. I have not tested what will happen if it is applied twice.
I have indeed succeeded in making multiple instances of SPFilter. I do have read your (and your collegeuages) comments regarding the load-balancing scenarious. I do believe this MUST be dealt with in further developments.
The pivot-point for my initialisation-problem was with the static boot-strap code for OpenSaml. I did oversee that. When I included the identical static code for that, things seems to be working in my Signing-filter. At least as to the point where I can do SPMetadata.getInstance(), and that suffices to me, and thanks to that!
Nevertheless: Why is this boot-strap code not put in the ContextListener, and why is all other instance-initialization not put there also? Isn't it a proper point for such initialisations and destructions?
In OIOSAML-JAVA there seems to exist several singleton-classes. Could you possibly state them et-all, and preferrable, in the order of their proper initialization?
The OIOSAML-JAVA code is not very well commented. A novice guy like me would very much appreciate comments. I don't know the opinion of Digitaliseringsstyrelsen in those regards, but it sure would make my world easier (and followers to come).
But, all in all:
For the current release of OIOSAML-JAVA 21188 I have delibratedly avoided doing modifications to the code in the original package, but that fact said, it leaves me with implementing "paralleled" code.
In future releases of OIOSAML-JAVA I would like to see:
- A re-usable Request-cache.- A re-uasble Configuration.- A dedicated Main-handler for generating SP-metadata.- A demo-interface not interferring with root ("/"), i.e. "/oiosamldemo")- Hows and whys of the META-INF/services overriddings as well as of the .jars in use (as opposed to out-of-the-box JAXB and JAXP, forgetting servlet-API for the time being).
This is all for now.Thank you for your patience!
Your input is very much appreciated.
We will discuss your input on the next status meeting.
I have a little bit more:
As you have stated previously, OIOSAML-JAVA does not incorporate
Signing. This is very odd, as much of the code in OIOSAML could
be perfectly re-used in such respect if properly "packaged".
When it comes to signing, I have to provide for the public-key of the
signing-web-app, in order to be able to do proper fingerprint
verification. I also need to perform CRL-checking for that certificate
(and its potential parents I guess). Either the API needs to be
"opened" (for re-usage), or a facility for
Signing-provider-metadata needs to be implemented at NemLogin-Admin.
Besides from above, I am experiencing perculiar problems with loggers
instantiated from the LoggerFactory of yours.
Normally I just use Log4J out-of-the-box. I guess the reason for you
using Sfl4j is because of OpenSaml (?). Nevertheless, when I am using
your bridged logger it fails to report line-numbers correctly (in my
SigningFilter that is). Same line-number everywhere in logging-entries
for same Java-class (?).
Can I possibly eliminate Sfl4J entirely from the package, or what?
Hi again Kasper,
My SigningFilter works as follows:
1) SigningFilter: The param-pattern of a request (GET/POST) is checked for "Signing required". If not, it is a pass-through. Otherwise 2.
2) An auto-post-form is formulated (for redirect to NemLog-in Signing) and the current request is cached. Then the auto-form is returned to the browser.
3) User interacts with NemLog-in Signing. NemLog-in signing returns a redirect to the browser which is to hit me with POST at same URI as of 1, but only with signing-result parameters from NemLog-in Signing.
4) SigningFilter is hit again. I validate and detect it is a result of a signing-interaction. An auto-post-form is formulated. This form will hit myself using URI from 1), but with combined parameters (custom+signing) and then using POST. I re-cache again, and return the form to the browser.
5) SigningFilter is hit again (POST). I validate again and delegate to the chain.
As can be seen, a GET at 1) will always be translated to a POST at 4).
Just a comment.
For me it seems that the demo-aspects of the package is somehow
mixed-in with the core functionality of the package. I think this is
somewhat true for the Java-code as well, and it bothers me.
I have also noticed following regarding the delivered jar-files:
- Current version-numbers are not easily discovered. Yoy will need to
investigate each MANIFEST one by one. Versions are significant,
especially when you upgrade from Xalan 2.7.1 to Xalan 2.7.2, as yoy
may encounter Illegal-Access-Exceptions if you don't take proper
provisons (I guess you may set a VM-option to a lower level).
- Overriding of the XML-handling by META-INF-services is not
documented at all. It can have unforeseen consequenses for an existing
application, and the real nead for such overrides need to be
documented, in my opinion, that is.
- The org.slf4j-slf4j-log4j12.jar delivered with the package is not
compatiable with the other content. One will need to upgrade to the
slf4j-log4j12-1.7.12.jar bridge or later.
- The not-yet-commons-ssl-0.3.9.jar is not in use at all(?)
- The build-method/tool (ivy? gant?) is unknown to me. Is this really
to be considered a part of the package?
Regarding the delivered demo-pages (.JSPs), some of them don't behave
as one would expect. Especially: After having performed a NemLogin,
the Home link on several pages doesn't work. It sends you to /saml and
This is all for now.
I am writing a document for our internal use, but it may be useful
for you too. Please comment if you feel to.
Thanks for sharing.
Why did you remove UserAssertionHolder?
The build tool is not to be considered a part of the package. It is
only used to make the distribution package.
Regarding the rest ... I will make a clean up task on the backlog for
Digitaliseringsstyrelsen to prioritize
Best regardsKasper Møller
Regarding elimination of the UserAssertionHolder:
In my opinion it is of limited value, as its content can only be relied upon for requests that have gone through the SPFilter.
The main purpose of having a thread-local to hold the UserAssertion must be to deliver it to program-code, that is executed in a request un-aware context. So, we make use of the current thread to carry the information - so to speak.
Please see my other posting regarding this, in which I suggest a more general solution.
I the OIOSAML.JAVA_DEMO package the UserAssertHolder thread-local variable is initialized from the SPFilter.
This will only make the assertion available (through the holder) from requests, that are matched to the URL-patterns defined for the SPFilter. This seems odd, as the assertion is stored in the HttpSession as well.
In order to make the UserAssertion globally available during the processing of a request, I will suggest that the UserAssertionHolder is to be replaced by a HttpSessionHolder class.
This class would then be initialized using af global filter, say HttpSessionFilter, that will make the current HttpSession available on the executing thread anywere.
This filter will ofcource need to be mapped to the URL-pattern: /*
I think this approach is much better, and I don't think it will compromize any memory-leak or security considerations. I appreciate any comments regarding this solution of mine.
My implementation of the HttpSessionFilter is very simple. One only need to implement the HttpSessionHolder similar to UserAssertionHolder. Here is the code for the filter:
public final class HttpSessionFilter implements Filter
public void init(FilterConfig arg0) throws ServletException
public void destroy()
public void doFilter(ServletRequestreq, ServletResponseres, FilterChainchain)
throws IOException, ServletException
if (!(req instanceof HttpServletRequest))
// Clear on out
HttpSessionHolder.set( null );
I forgot to check "get email on replies".
Silly that isn't the default, and that one cannot change that
property for any thread in here.
Thanks for your input.
Which usage scenario needs the above implementation?
can be used across all requests in the presentation layer to get
access to the UserAssertion, and
dk.itst.oiosaml.sp.UserAssertionHolder.get() can be used in the
application layer if the call to the application layer comes from a
request that matched the URL-patterns defined for the SPFilter.
Regarding your comment "which scenarios?":
Isn't it a more flexible solution, to be able to delegate the
UserAssertion to other requests than SPFilter matched requests?
In my opinion it will only be a matter of configuring the WEB.xml
with URL-patterns for the HttpSessionFilter, and one could also take
the effort to implement a facade to HttpSession, that will only expose
read-only and limited properties of the "real" HttpSession.
I don't think "security" will be compromized, as long as
certain rules are obeyed, when the site is to be deployed.
Just to make things totally clear :)
The current solution makes authentication information available
across all request through the session state. Thus, in the
presentation layer you always have access to the authentication
information even if your ressource is not protected.
If you have needs that requires the authentication information to be
available in a business layer without access to the session state and
that code is called from ressources in the presentation layer that are
not protected ... then you need to do something more.
Your solution solves the issue about the need to have authentication
information available acroos all requests in the business layer ...
even if the ressource in the presentation layer calling the businiess
layer is not protected. Just curious ... in what situations do you
have the need to call secure service in the business layer from
unprotected ressources in the presentaion layer? Logging purposes?
The fundamental problem is that session state and authentication
state is mixed. These two matters should be seperated as according two
the seperation of concerns principle. E.g. the current solution always
requires a distributed cache to backup the session state in a load
balanced setup in order for authentication to work properly. It would
be more elegant if the authentication information was encapsulated in
a secure cookie independant of the session cookie. The implementation
of the authentication cookie could then be made in a manner that does
not require a distributed cache. Hereafter, a AuhtenticationFilter
could be made that is dependant on the authentication cookie in the
samme manner as your HttpSessionFilter is dependant on the session state.
So I agree that your approach is better ... I would just rename your
filter to AuhtenticationFilter and then only store the authentication
information instead of the whole session state in order to seperate
concerns and incapsulate the logic about authentication. If you then
later on changes the OIOSAML.Java implementation to depend on an
authentication cookie ... you just change your AuthenticationFilter to
extract the authentication information from a cookie instead of the
Best regardsKasper V. Møller
Thank you for your reply - very much appreciated!Here are a few
comments/feedbacks of mine:
1) As of "..doing something more..":
Is this a problem, I mean, if PID or CVR+RID is "available"
in the presentation layer (the GUI)? This will be hard to circumvent,
as I am currently implementing the scenario for NemLog-in Signing.
Anyways, I rely on, that the programmers of any presentation-layer
will (and shall not) expose the CPRNR of any citizen. Is it critical
not to have the CVR+RID exposed?
2) As of "..calling secure services...":
I don't have that need. For me it is a practical issue, and that
is why I request for a more globally available UserAssertionHolder
(holding authenticated or not).
By the way, I suspect that OIOSAML-JAVA may contain flaws regarding
JSP-access to UserAssertionHolder - but don't take my word for that. I
have made modifications, in order to have all the JSP resources at
"/" and "/sp" located beneath "/oiosamldemo".
3) Load-balancing etc.
I do see you point regarding storing assertion-info in a cookiee. Is
this really the ultimate solution? I don't mean to be rude, but is it
SSO or not?
Besides from all of the above, I am having a struggle designing the
scenario for NemLog-in Signing - in this sceanrio one need to
"persist" the "proof" in some business-logic out
of my hands.
Thank you Kasper!
Here I am just referring to your solution :)
I do not see any issue in that PID or CVR+RID is available in the
If UserAssertionHolder is not available ... you could assume that
user i not authenticated.
OIOSAML.Java is SSO out of the box in a single server setup. In a
load balanced setup one needs to make sure that the session is placed
in a single available place (a single process, database or a
distributed cache) in order for the component to behave correctly.
An alternative to the above is running sticky sessions. Most pepole
chose this strategy due to simplicity :)
Thanks again. I will have a look into sticky sessions...
Where can I download XML schemas for the SAML-ticket XML returned
I would like to see those too!
I would also like to see the .XSDs for our SP-metadata as well as for
You will find all SAML2 related XDS's here:
... and you are properly looking for this specific XSD:
We were about to implement some change requests to an application so
we thought we might want to update OIOSAML along with these changes.
We changed the OIOSAML, got compile errors and fixed these. Then
strange things happend:
[02:42:45 PM] Deployment cancelled. [02:42:45 PM] ----
Deployment incomplete ----. [02:42:45 PM] Remote deployment
failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer) ####
Cannot run application Flsv due to error deploying to
IntegratedWebLogicServer. [Application Flsv stopped and
undeployed from Server Instance IntegratedWebLogicServer]
The application is based on Oracle ADF 220.127.116.11 and runs on a
WebLogic 10.3.5. We cleared temp folders, restarted servers and so on,
but it did not work until we deployed another completely unreleated
application to the same server (the JDeveloper integrated Weblogic
server). The problem seems to be WebLogic related, but somehow
triggered by the OIOSAML update.
Has anybody experienced anything like this?
It turned out that setting the log-level to debug revealed the error:
weblogic.application.ModuleException: authorityInfoAccess at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1512)......
Caused By: java.lang.NoSuchFieldError: authorityInfoAccess
I've added the "oiosaml-sp.crl.period" setting to my
oiosaml-sp.properties, but the error remains.
OK, so the problem is here:
private static final String AUTH_INFO_ACCESS = X509Extension.authorityInfoAccess.getId();
I'm running on Java 1.6.0_24 which is >= java 6.0 which is required.
I've tried to compile (java 1.6) a simple java file only importing
org.bouncycastle.asn1.x509.X509Extension and then do private static
final String AUTH_INFO_ACCESS = X509Extension.authorityInfoAccess.getId();
Can anybody tell me what is going on? Does oiosaml.java 21188 require
a newer java than version 6?
Our demo setup is running on 1.6.0_45.
The class X509Extension with field
public static final ASN1ObjectIdentifier authorityInfoAccess = new ASN1ObjectIdentifier("18.104.22.168.22.214.171.124.1");
is located within the org.bouncycastle-bcprov-jdk15on.jar library.
Are you sure you are referencing this library at runtime?
Thanks for your reply. I made a mistake in my test-code in
Eclipse. I accidentally had another jar-file (some pdf-toolbox stuff)
in my build path that actually had the exact same
org.bouncycastle.asn1.x509.X509Extension file, and this fooled me in
to believe that the org.bouncycastle.asn1.x509 package was included in Java.
Thanks for documenting "oiosaml-sp.crl.period=0" ! I have
just discovered its usage by myself when investigating why my
self-signed certificates (working with 9918 version) were now
considered as revoked.
For information, on my Debian GNU/Linux 7 with Tomcat 7.0.28 package,
21188 demo application fails to start with:
May 01, 2015 10:54:50 AM org.apache.catalina.core.StandardContext
filterStartSEVERE: Exception starting filter
I had to remove "WEB-INF/lib/log4j-log4j.jar" (from 2006 !)
and "WEB-INF/lib/org.slf4j-slf4j-*.jar" files from WAR to
get it deployed properly.
Thanks for sharing. I have listed this as an issue.
1. To workaround the above issue we have added the correct jar implementation: org.slf4j-slf4j-log4j12.jar correspoding to the API specified in org.slf4j-slf4j-api.jar.
2. We have also noticed that a velocity.log file gets created in the root directory (not ./logs) of our container, and that it contains this exception:
Trying to use logger class org.apache.velocity.runtime.log.AvalonLogChute
Couldn't find class org.apache.velocity.runtime.log.AvalonLogChute or necessary supporting classes in classpath.
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
The above issue is caused because the library: avalon-logkit-2.1.jar is missing.
Actually we have disable the velocity.log, since it contains very little relevant information for us.
So editing the properties file: \org\apache\velocity\runtime\defaults\velocity.properties in org.apache.velocity-velocity.jar and setting: runtime.log.logsystem.class=org.apache.velocity.runtime.log.NullLogChute fixes this.
It might be a better idea that a velocity.properties was supplied with the project to avoid the default properties file from being used. Editing the default velocity.properties in the jar should be a no-go.
3. Lastly we have also noticed the following warning in our logs, which could be removed without much effort
log4j:WARN No appenders could be found for logger (dk.itst.oiosaml.configuration.FileConfiguration).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
ITS, Aalborg University