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.

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.

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.

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

Hi there,

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:

https://test-nemlog-in.dk/Testportal/certifikater/IntegrationTestSigning.zip

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.

/Aron

Hi again,

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:

private 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?

Thanks.

/Aron

Hi Aron

Reagarding troubleshooting your integration with NemLog-in Signing Service ... you should write to nemlogin@digst.dk. 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.

Best regards

Kasper V. Møller

Hi Kasper,

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?

/Aron

Hi Aron

As you can see in the link below ... filters are applied in a chain.

http://otndnld.oracle.co.jp/document/products/as10g/101300/B25221_03/web.1013/b14426/filters.htm

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.

Best regards

Kasper V. Møller

Hi Kasper,

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!

Best regards,
/Aron

Hi Aron

Your input is very much appreciated.

We will discuss your input on the next status meeting.

Best regards

Kasper V. Møller

Hi Kasper,

Thanks.

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?

Best regards,

Aron

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.

/Aron

I am writing a document for our internal use, but it may be useful for you too. Please comment if you feel to.

/Aron

Hi Aron

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 regards
Kasper Møller 

Hi Kasper,

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

/Aron

Hi Aron

Thanks for your input.

Which usage scenario needs the above implementation?

e.g. request.getSession.getAttribute("dk.itst.oiosaml.userassertion") 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.

Best regards

Kasper Møller

Hi Kasper,

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.

Hi Aron

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

Best regards
Kasper V. Møller

Hi Kasper,

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!

/Aron

Hi Aron

1)

Here I am just referring to your solution :)

I do not see any issue in that PID or CVR+RID is available in the presentation layer.

2)

If UserAssertionHolder is not available ... you could assume that user i not authenticated.

3)

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

Best regards

Kasper V. Møller

Thanks again. I will have a look into sticky sessions...

Best regards,

Aron

I would like to see those too!

I would also like to see the .XSDs for our SP-metadata as well as for the Idp-metadata.

/Aron

Hi

You will find all SAML2 related XDS's here:

https://docs.oasis-open.org/security/saml/v2.0/

... and you are properly looking for this specific XSD:

https://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd

Best regards

Kasper Møller

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
    at dk.itst.oiosaml.sp.metadata.CRLChecker.(CRLChecker.java:76)
    at dk.itst.oiosaml.sp.service.SPFilter.(SPFilter.java:107)

I've added the "oiosaml-sp.crl.period" setting to my oiosaml-sp.properties, but the error remains.

OK, so the problem is here:

dk.itst.oiosaml.sp.metadata.CRLChecker

line 47:

import org.bouncycastle.asn1.x509.X509Extension;

line 76:

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?

Hi Mads

Our demo setup is running on 1.6.0_45.

The class X509Extension with field

public static final ASN1ObjectIdentifier authorityInfoAccess = new ASN1ObjectIdentifier("1.3.6.1.5.5.7.1.1");

is located within the org.bouncycastle-bcprov-jdk15on.jar library. 

Are you sure you are referencing this library at runtime?

Best regards

Kasper Møller

Hi Kasper,

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.

Hi Martin

Thanks for sharing. I have listed this as an issue.

Best regards
Kasper Møller 

Hi,

To supplement.

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.

java.lang.NoClassDefFoundError: org/apache/log/format/Formatter

      at java.lang.Class.forName0(Native Method)

        at java.lang.Class.forName(Unknown Source)

        at org.apache.velocity.util.ClassUtils.getClass(ClassUtils.java:63)

        at org.apache.velocity.util.ClassUtils.getNewInstance(ClassUtils.java:95)

        at org.apache.velocity.runtime.log.LogManager.createLogChute(LogManager.java:147)

        at org.apache.velocity.runtime.log.LogManager.updateLog(LogManager.java:208)

        at org.apache.velocity.runtime.RuntimeInstance.initializeLog(RuntimeInstance.java:728)

        at org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:240)

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.

/Regards

Morten Binderup-Ernstsen

ITS, Aalborg University