Thomas Krille

Give up the add-ons and merge them into OSIAM

2

@dacrome, @wallner and I already talked about this idea. We've merged the auth-server and resource-server to make OSIAM a unified product. The add-ons provide essential services, that are needed to...

- [ ] Local with PostgreSQL - [ ] Local with MySQL - [ ] Remote (Docker + OSIAM)

Deprecate support for WAR deployments

6

I propose that we deprecate the support for WAR deployments with version 3.1. This means we will remove the support in 3.4 or 4.0.

Deprecate AJP support

1

I propose that we deprecate the support for AJP with version 3.1. This means we will remove the support in 3.4 or 4.0.

We should try to run the compliance tests after each push to master. See also https://github.com/osiam/osiam/issues/309.

* With Spring Session * Initial support for JDBC * JDBC is default * Support for Hazelcast and Redis will be added later on

* Use default Spring Security OAuth stuff * Initially, in-memory tokens are still the default, JWT can be enabled * Initially, signing key is configured in `config.yaml` and does not...

Add registration feature

5

Users should be able to register an account with OSIAM by themselves. This feature should be working more or less like the existing registration of the Add-On Self Administration. I...

We must implement this according to [section 3.9](https://tools.ietf.org/html/rfc7644#section-3.9) of the SCIM spec.

I think we should write it down somewhere, so we don't forget it?! I mean, it's drop dead simple: push the tag, but anyways. I don't think we need this...