Allow java-saml to be used in non-JavaEE containers

[ashleymercer]

Fixes #115

The default Auth and ServletUtils classes were previously tied to the javax.servlet APIs, so couldn't be used in other frameworks (e.g. Play).

Instead, introduce abstract HttpRequest and HttpResponse classes which can be used as wrappers around different request and response objects depending on the framework (plus default javax implementations).

A nice result of this is that Auth and ServletUtils can move to the core module - the toolkit jar now contains only the javax.servlet wrappers.

[coveralls]

Coverage decreased (-0.3%) to 94.845% when pulling 89ce157 on ashleymercer:master into 9274e6b on onelogin:master.

[coveralls]

Coverage increased (+0.4%) to 95.544% when pulling 7793000 on ashleymercer:master into 9274e6b on onelogin:master.

[pitbulk]

That solution breaks environments that currently use HttpServletRequest and HttpServletResponse on Auth.

[markkolich]

@pitbulk any update on this PR? I'm finding myself in the same boat as @ashleymercer here. Specifically, I'd like to pass my own version of com.onelogin.saml2.http.HttpRequest into com.onelogin.saml2.Auth, but Auth appears to be strongly tied to javax.servlet.

I'm having to implement my own skinny version of HttpServletRequest and pass that into Auth instead, which is effectively a wrapper on top of my underlying request object. If I could only pass my own HttpRequest implementation into Auth that would get me most of the way there.

Somewhat related, it seems that com.onelogin.saml2.http.HttpRequest should actually be an interface. Your default implementation could be backed by javax.servlet, but for those who want to implement their own version of HttpRequest you could leave that door open as well. E.g., my own version of ServletUtils#makeHttpRequest().

[pitbulk]

We need to find a solution compatible with current Auth API...

Since request and response attributes from the Auth class are private, I'm ok replacing then from HttpServletRequest/HttpServletResponse to HttpRequest/HttpResponse, but we need to
keep the way of initializing the Auth class with HttpServletRequest and HttpServletResponse objects, so be able to transform those objects into HttpRequest/HttpResponse objects.

[markkolich]

@pitbulk I think it would be completely reasonable to add a few additional constructors to Auth that take a com.onelogin.saml2.http.HttpRequest and com.onelogin.saml2.http.HttpResponse instead of a HttpServletRequest and HttpServletResponse.

In other words, leave the existing constructors alone (for backwards compatibility sake), but add a means for consumers to pass their own HttpRequest and HttpResponse instances into a new set of Auth constructors.

I still contend though that definitions like HttpRequest and HttpResponse should be interfaces, not concrete classes. Just looking at how java-saml uses the request and response, the toolkit only uses a small subset of methods defined by HttpServletRequest and HttpServletResponse. I think it would be much cleaner if HttpRequest and HttpResponse were interfaces that defined only what java-saml needs from each entity, instead of requiring the consumer to pass around implementations of HttpServletRequest and HttpServletResponse.

[antonpetkoff]

@markkolich +1
We can't integrate java-saml with the Play Framework because of the Servlet API dependence...

[pitbulk]

As far as the solution keep compatible with the current Auth class, I'm ok merging it.

[slorber]

Hey, wondering if this can be used with play now?
I've seen the parameter "stay" which avoid writing to the response and instead just returns the url, is this enough to solve the problem?

#86

[markkolich]

FWIW, I think #395 now supersedes this PR