removed outdated documentation (everything should be on the wiki now)
parent
e707219a75
commit
2ea9fa5146
|
@ -1,46 +0,0 @@
|
|||
This project is built on Spring 3.1 and Spring Security 3.1, making heavy use of the OAuth2 module of Spring Security OAuth (SECOAUTH). Wherever sensible, we have tried to make use of existing functionality in SECOAUTH, Spring, and Spring Security.
|
||||
|
||||
This project tracks against the development version of SECOAUTH, which is included in the build directories as a Git submodule. This submodule must be initialized before the main project can be built. Once SECOAUTH stabilizes to sufficient point, this project will remove its submodule reference and instead use a Maven dependency.
|
||||
|
||||
To initialize the submodule:
|
||||
git submodule init
|
||||
git submodule update
|
||||
|
||||
This project is intended to be a standalone OpenID Connect Server. Extension and customization of this server can be accomplished by configuration through Spring configuration files, injected functionality through new Beans, and overlay of views and static resources (using Maven War Overlay or similar functionality).
|
||||
|
||||
|
||||
There is a JWT library that handles serialization/deserialization and manipulation of JWTs. We have our own implementation of OAuth2AccessToken called OAuth2AccessTokenEntity which is backed by a JWT object and returns the serialized version of the JWT as the token's Value field.
|
||||
|
||||
|
||||
Managing users:
|
||||
UserDetailsService - used by Spring Security's AuthenticationProvider to represent the current user (loads a user from a given user id)
|
||||
AuthenticationUserDetailsService - Used by Spring Security to load a user from an authentication token
|
||||
UserInfoRepository - repository of user information that is fed into the UserInfoEndpoint's service
|
||||
|
||||
Managing OAuth tokens:
|
||||
AuthorizationServerTokenServices - provide tokens for the authorization server
|
||||
|
||||
Managing OAuth clients:
|
||||
ClientDetailsService - provide OAuth client information (used for OpenID Connect Clients)
|
||||
|
||||
|
||||
|
||||
Modules
|
||||
-------
|
||||
|
||||
The project uses a multi-level Maven and git repository sutrcture. The main project is split into the following modules:
|
||||
|
||||
- openid-connect-common: common classes, service and repository interfaces, and model code. Also includes full JWT library.
|
||||
- openid-connect-server: IdP/server implementation, includes implementations of services and repositories for use by server.
|
||||
- openid-connect-client: RP/client implementation, built around spring security filters.
|
||||
- spring-security-oauth: Git submodule that points to the Spring Security OAuth Git repository. Will be removed once a reliable milestone is reached upstream (see note above).
|
||||
|
||||
|
||||
|
||||
Maven War Overlay
|
||||
-----------------
|
||||
|
||||
One of the best ways to build a custom deployment of this system is to use the Maven War Overlay mechanism. In essence, you make a new Maven project with a "war" disposition and make it depend on the openid-connect-server module with the Maven Overlay plugin configured. Any files in your new project will be built and injected into the war from the other project. This action will also overwrite any existing files.
|
||||
|
||||
For instance, to overwrite the data source configuration in the main server war file, create a file named src/main/webapp/WEB-INF/data-context.xml that contains the dataSource bean. This file will completely replace the one that's in the originally built war.
|
||||
|
Binary file not shown.
Before Width: | Height: | Size: 191 KiB |
Binary file not shown.
Before Width: | Height: | Size: 86 KiB |
|
@ -1,39 +0,0 @@
|
|||
Changelog
|
||||
|
||||
Updated on 3/6/2012
|
||||
|
||||
Connect:
|
||||
* "Authorization Code Flow" diagram: changed step B to be a redirect rather than a JSON response object.
|
||||
|
||||
Updated on 2/21/2012
|
||||
|
||||
OAuth2:
|
||||
* Renamed "Access Code Flow" to "Authorization Code Flow".
|
||||
|
||||
* Changed all references to "User" to "Resource Owner".
|
||||
|
||||
* Changed final "Response"s to "JSON respones object"s.
|
||||
|
||||
* Added initial "Authenticate Resource Owner" step to Authorization Code Flow
|
||||
|
||||
Connect:
|
||||
|
||||
* Changed final "Response"s to "JSON respones object"s.
|
||||
|
||||
Updated on 2/7/2012
|
||||
|
||||
OAuth2:
|
||||
* Removed refresh_token from the Access Token response on the Client Credentials flow.
|
||||
Ref: http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4.3
|
||||
"A refresh token SHOULD NOT be included."
|
||||
|
||||
* Changed "Consumer" to "Client".
|
||||
|
||||
Connect:
|
||||
* Changed "Consumer" to "Client".
|
||||
|
||||
* Clarified required/optional wording. Parameters are REQUIRED unless otherwise stated.
|
||||
|
||||
* Implicit Flow: changed wording on redirect_uri requirement in the Authorization Request. Now reads "required IFF the client has pre-configured more than one value with the service provider".
|
||||
|
||||
* Diagram 3 was renamed to "Optional Steps" (from "Additional Steps"), as these steps may or may not be taken and may be done in any order. Added "openid" to the schema parameter in the UserInfo Request.
|
Loading…
Reference in New Issue