Remove unused exception declaration.

git-svn-id: https://svn.forgerock.org/openig/trunk@561 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
OPENIG-228 CR-4486 Align OAuth2 client and resource server configuration


git-svn-id: https://svn.forgerock.org/openig/trunk@562 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
OPENIG-279 CR-4486 Rename "handlerObject" property to "handler"

git-svn-id: https://svn.forgerock.org/openig/trunk@563 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
CR-4499 Fix for OPENIG-304: Document explicitly that routes inherit objects from parent configurations

git-svn-id: https://svn.forgerock.org/openig/trunk@564 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
OPENIG-278 CR-4474 Implement OpenIG Session using JWT and stores it in a cookie

OpenIG used to provide a default Session implementation based on the
underlying Servlet container's HttpSession. This changeset intends to
gives to the user the ability to change the session persistence
strategy (in other words: changing the Session implementation).

This can be done at the global level (in the config.json, declaring a
SessionFactory object named 'Session') or on a per-route basis (with the
new 'session' attribute).
When an Exchanges comes into a route that declares a new session type, a new
session is build (no existing session items are propagated) and replace
the old session. When the exchange exits the route, the new session is closed
(notify the session that it's time to persist its content) and is replaced
by the old one. Really like a push/pop stack mechanism.

Notice that the 2 sessions are completely separated (cannot access the old
content from the new and vis-versa). First, that would defeat the purpose of
different session persistence modes (if items are propagated, where should
I persist them ?). Secondly, Session is not intended to share data between
handlers/filters: the Exchange is basically a request-scoped Map that is
designed for that purpose.

The JWT based session is a session implementation whose persistence is done
using an HTTP Cookie, the session's content being serialized as JSON (usable
types are constrained, see list below) and used as the payload of an
encrypted JSON Web Token (JWT).

The use of the JWT session has a few constraints:
 * HTTP Cookies are size-limited to 4K -> Small objects can be stored
 * Only JSON compatible types are supported:
    * null
    * Java primitive types + their boxed equivalent
    * Strings (and any CharSequence)
    * List and Map (of the supported types, recursively)
 * Same client performing concurrent HTTP invocations (so within the
   same HTTP session) that will modify their own session content will
   see inconsistencies in the session. This is due to the fact that the JWT
   session is not shared, each concurrent Thread has its own instance and
   can modify it at will. At the end of the processing, each Thread will
   serialize its own session's content regardless of other Threads.

git-svn-id: https://svn.forgerock.org/openig/trunk@565 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
OPENIG-279 Fix javadoc that was still referring to 'handlerObject'

git-svn-id: https://svn.forgerock.org/openig/trunk@566 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
CR-4515 Fix for OPENIG-306: Document key store, key manager, and trust manager configuration

git-svn-id: https://svn.forgerock.org/openig/trunk@567 dbb9e58e-28e6-4ce0-90e8-f11d9605b710
CR-4522 Fix for OPENIG-309: Document new JwtSession capability

git-svn-id: https://svn.forgerock.org/openig/trunk@568 dbb9e58e-28e6-4ce0-90e8-f11d9605b710