WIP: Initial commit for openid4j support

[bdemers]

Moved this commit from master into a branch until feature is complete

[fpapon]

@bdemers it would be nice to have this in the 2.0.0 :)
Thoughts?

[bdemers]

IMHO, OAuth2 (and OIDC) is a must-have for 2.0. I think the openid4j project is dead though.
But... it's a good start of where the bits need to be plugged in.

I've been thinking about options in the back of my head for a while now. And I need to start writing them down (both code and on the dev list). I'll add a note here for now, because i'm thinking about it.

There are a couple of main use cases we need to target (and even more nice-to-haves)

• Resource Server support - Shiro has Bearer Token support for this, which is half the battle, we could add "opaque" access token validation as a Realm.
  I worry about generic JWT access token validation as each vendor recommends different validation (as JWTs are NOT part of the OAuth spec), but other libraries have support, so...

• OAuth 2.0 Auth Code Flow - there will be a heavy dependency on the servlet (or similar) specs for this

• OIDC support (similar to previous)

All of these options depend on an HTTP client component which Shiro doesn't have. It's easy enough to add, but we may need to expose some of the underlying bits of said client, to allow for a whole host of client-to-server communication. (timeouts, HTTP headers for firewall negation, proxies, etc).

Mostly just quick thoughts, I need to dig into this again

[fpapon]

IMHO, OAuth2 (and OIDC) is a must-have for 2.0. I think the openid4j project is dead though.
But... it's a good start of where the bits need to be plugged in.

I've been thinking about options in the back of my head for a while now. And I need to start writing them down (both code and on the dev list). I'll add a note here for now, because i'm thinking about it.

There are a couple of main use cases we need to target (and even more nice-to-haves)

* Resource Server support - Shiro has Bearer Token support for this, which is half the battle, we could add "opaque" access token validation as a Realm.
  I worry about generic JWT access token validation as each vendor recommends different validation (as JWTs are NOT part of the OAuth spec), but other libraries have support, so...

* OAuth 2.0 Auth Code Flow - there will be a heavy dependency on the servlet (or similar) specs for this

* OIDC support (similar to previous)

All of these options depend on an HTTP client component which Shiro doesn't have. It's easy enough to add, but we may need to expose some of the underlying bits of said client, to allow for a whole host of client-to-server communication. (timeouts, HTTP headers for firewall negation, proxies, etc).

Mostly just quick thoughts, I need to dig into this again

Nice, you can add on the brainstorm page on Confluence (until I have my access rights :) ).
So we can close this PR IHMO.

[bdemers]

Done! https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming#Version2Brainstorming-OAuth2.0Support