Destroyed Architecture (markdown)
Justin Richer
parent
48fb6d4cb2
commit
76a0721333
102
Architecture.md
102
Architecture.md
|
|
@ -1,102 +0,0 @@
|
|||
The MITREid Connect server 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). We currently support the Authorization Code flow, and intend to eventually support others.
|
||||
|
||||
MITREid Connect 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. Because of this, much of the functionality of MITREid Connect is hidden in Spring context configuration files and may not be readily apparent when examining the codebase. This architecture document will attempt to lay out which portions of the server implementation reside in our own code, and which portions are delegated to the SECOAUTH library.
|
||||
|
||||
We are using JPA with Eclipselink and either an internal HSQL or external MySQL databases for token, client, and user data persistence.
|
||||
|
||||
## Modules
|
||||
|
||||
The project uses a multi-level Maven and git repository structure. The main project is split into the following modules:
|
||||
|
||||
* openid-connect-common: common classes, service and repository interfaces, and JPA-annotated model code.
|
||||
* 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 Configuration
|
||||
|
||||
We are using the SECOAUTH 'authorization-server' element in our spring-servlet.xml (Spring configuration file, in openid-connect-server src/main/webapp/WEB-INF). This element stands up several SECOAUTH beans, and allows customization by injecting replacements for some of their default beans.
|
||||
|
||||
```
|
||||
<oauth:authorization-server
|
||||
client-details-service-ref="defaultOAuth2ClientDetailsEntityService"
|
||||
authorization-request-manager-ref="authorizationRequestManager"
|
||||
token-services-ref="defaultOAuth2ProviderTokenService"
|
||||
user-approval-handler-ref="tofuUserApprovalHandler"
|
||||
authorization-endpoint-url="/authorize"
|
||||
token-endpoint-url="/token">
|
||||
|
||||
<oauth:authorization-code authorization-code-services-ref="defaultOAuth2AuthorizationCodeService"/>
|
||||
<oauth:implicit />
|
||||
<oauth:refresh-token/>
|
||||
<oauth:client-credentials/>
|
||||
<oauth:custom-grant token-granter-ref="chainedTokenGranter" />
|
||||
<oauth:custom-grant token-granter-ref="jwtAssertionTokenGranter" />
|
||||
|
||||
</oauth:authorization-server>
|
||||
```
|
||||
|
||||
Following is a list of the important SECOAUTH beans we are using out-of-the-box. This is not an exhaustive list; but these beans contain most of the functionality that we care about:
|
||||
* org.springframework.security.oauth2.endpoint.AuthorizationEndpoint
|
||||
* org.springframework.security.oauth2.endpoint.TokenEndpoint
|
||||
* org.springframework.security.oauth2.code.AuthorizationCodeTokenGranter
|
||||
* org.springframework.security.oauth2.provider.code.InMemoryAuthorizationCodeServices
|
||||
|
||||
Following is a list of the custom beans we are injecting:
|
||||
* org.mitre.oauth2.service.impl.DefaultOAuth2ProviderTokenService
|
||||
* org.mitre.oauth2.service.impl.DefaultOAuth2ClientDetailsEntityService
|
||||
* org.mitre.openid.connect.token.ConnectTokenEnhancer
|
||||
* org.mitre.openid.connect.token.JdbcUserApprovalHandler [TODO, not fully implemented yet]
|
||||
* JpaUserInfoRepository
|
||||
* OAuth2ClientRepository
|
||||
* JwtSigningAndValidationServiceDefault
|
||||
|
||||
The diagram below shows how all of these pieces fit together. **_TODO: move diagrams to wiki_**
|
||||
|
||||
|
||||
## Endpoints
|
||||
|
||||
The OAuth2 and OpenID Connect endpoints are currently set to the following values:
|
||||
|
||||
* Authorization endpoint: /authorize
|
||||
* Token endpoint: /token
|
||||
* Token introspection: /introspect
|
||||
* Token revocation: /revoke
|
||||
* JWK: /jwk
|
||||
* User info: /userinfo
|
||||
* Provider configuration: /.well-known/openid-configuration
|
||||
|
||||
These endpoints are compliant with the OpenID Connect family of specifications. For instructions regarding how to interact with these endpoints, please see the specifications at http://openid.net/connect.
|
||||
|
||||
## Tokens
|
||||
|
||||
We are using the SECOAUTH TokenEndpoint, with several custom beans injected that allow us to customize the tokens we produce and consume. We are using structured JWT (JSON Web Token) Bearer tokens. These tokens can be optionally signed using the JWE / JWK specifications.
|
||||
|
||||
We use the NimbusDS JWT-JOSE library to handle all JWT and JOSE functions. Our implementation of the SECOAUTH OAuth2AccessToken interface, OAuth2AccessTokenEntity, implements our JWT interface and returns the serialized version of the JWT from its Value field.
|
||||
|
||||
For more information:
|
||||
* [JWS](http://tools.ietf.org/html/draft-ietf-jose-json-web-signature)
|
||||
* [JWE](http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption)
|
||||
* [JWK](http://tools.ietf.org/html/draft-ietf-jose-json-web-key)
|
||||
* [JWA](http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms)
|
||||
* [JWT](http://tools.ietf.org/html/draft-ietf-oauth-json-web-token)
|
||||
|
||||
## 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
|
||||
|
||||
An in-memory Authentication Manager is configured in [user-context.xml](https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-server/src/main/webapp/WEB-INF/user-context.xml).
|
||||
|
||||
//Which of these have we implemented and which are straight SECOAUTH?
|
||||
|
||||
## Clients
|
||||
ClientDetailsService - provide OAuth client information (used for OpenID Connect Clients)
|
||||
|
||||
## 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.
|
||||
|
||||
[How to set up an Overlay Project](Maven-Overlay-Project-How-To)
|
||||
|
||||
Loading…
Reference in New Issue