osiam / auth-server

[DEPRECATED] OSIAM auth-server

OSIAM - Open Source Identity and Access Management

Active development of this project has stopped.

OSIAM is a secure identity management solution providing REST based services for authentication and authorization. We achieve this by implementing two important open standards:

• OAuth 2.0
• SCIM 2.0

OSIAM is published under the MIT licence, giving you the greatest freedom possible to utilize OSIAM in you project or product. Watch our blog to stay informed about releases and upcoming changes.

Use cases

• Single app with OSIAM as free backing store for users and groups and local auth service.
• Distributed app with OSIAM as central identity store and auth service.
• Publish your app's API with OSIAM as auth service for 3rd-parties and allow safe access to your user's data.

Quick Start

Download the latest version of OSIAM:

curl -L https://dl.bintray.com/osiam/downloads/osiam/3.0/osiam-3.0.war -o osiam.war

Make the .war file executable:

chmod +x osiam.war

Start OSIAM:

./osiam.war

After some seconds, OSIAM should be fully running. You can now retrieve your first access token:

curl -H "Authorization: Basic ZXhhbXBsZS1jbGllbnQ6c2VjcmV0" -X POST -d "grant_type=client_credentials&scope=ADMIN" http://localhost:8080/oauth/token

You can now start to setup OSIAM, by changing the administrator's password and add your own OAuth client. Please see the Installation and Configuration Manual for details.

Documentation

Learn how to install and configure OSIAM for production in the documentation.

Components

• osiam handles the authentication and authorization based on OAuth 2.0 and holds the SCIM based user data
• addon-self-administration provides account management self-service as a web application
• addon-administration lets you administer users and groups via a web application

Easy customization

Every visual aspect of OSIAM's components can be easily customized by supplying your own templates, stylesheets and scripts to make OSIAM integrate seamlessly with your application. Read the customization guide to learn more.

Snapshots

To use the latest snapshot of OSIAM just download it from JFrog OSS: https://oss.jfrog.org/repo/org/osiam/osiam/latest-SNAPSHOT/

Scroll down to the bottom of the page and select the latest WAR file.

Issue Tracker

Please report issues, bugs and feature requests via [the issue tracker] (https://github.com/osiam/osiam/issues).

Get involved

Help is very appreciated. Please read the contributors guide to learn how to get started.

auth-server's Issues

Properties for Connection-Pool

We need properties for the connection pool (how many connection and the connection timeout) of the internal connector4java. And we need also a property for the DB-Pool-Size (hikari).

Switch from xml to java configuration

The xml configuration should be removed and migrate to java configuration. The Spring Framework provides java configuration since version 3.1 and this can be done as a first step to Spring Boot. We already made good experience with the configuration migration in the self-administration. We should check if this step can be used to migrate Spring OAuth2 version 1.0.5.RELEASE to the latest version 2.0.7.RELEASE to take advantage of the new configuration annotations. Maybe also a bump of the Spring Security version to the latest 4.0.1.RELEASE is possible.

Auth Server shall have a URL for Logout

We are using OSIAM as IDM for multiple small applications with the OAuth2 authorization flow. The customer wants a logout functionality, so that the user is also logged out from OSIAM.

My suggestion would be: When the user clicks the logout button in our application, he is forwarded to a special logout URL of the auth-server (similar to the redirect URL for login). OSIAM then invalidates the access token issued to this session. A message, that the user has been logged out is displayed and the input fields to log in again. After successful login, the user is again redirected back to the application.

It is important for our use-case, that not all sessions of this user are logged out, since one account may be used by more than one person in parallel. This could be an additional feature (log me out on all browsers/devices), which we don't need at the moment.

Cache client details per request

I've noticed that 1 request to an OAuth-protected resource on the resource server leads to several roundtrips to the client database. Seems that Spring Security OAuth calls clientDetailsService.loadClientByClientId(clientId) for almost every single attribute it has to know about. We should somehow cache the result of clientDetailsService.loadClientByClientId(clientId) on a per request basis.

Single sign-on broken

Currently if the user leaves the oauth2 approval page, the session of the auth-server will be invalidated shortly before the redirect to the web application. Furthermore the session with the auth-server will be invalidated too, if the user denies their approval. Last but not least, if implicit approval is true or there is an approval, that's still valid for some reason, the session will also be invalidated. That's obviously not the right behavior to support single sign-on and must be fixed.

Inactive user, weird error when getting access token

When i am trying to get access token with not existing user, I get error which tells me what happen, the same situation when user is proper but password is incorrect.
Weird behaviour occurs when i am passing proper user credential but for user for which active is not defined on database.
If I set active on true, access token come in standard way. When I set active on false I get:
{"error":"invalid_grant","error_description":"The user with the username 'a1aaaaaaaa' is disabled!"}
which is OK.
But when active is not defined I get html page with:
"There is an internal problem with the client authorization. Please contact your client."
I think that this information is confusing.
Maybe it will be better to treat not defined active as active=false or not letting creating user without defined this field?
In your documentation I found:

"To create a new user you need to send the user input as JSON via POST to the URL
curl -i -H "Accept: application/json" -H "Content-type: application/json" -H "Authorization: Bearer $YOUR_ACCESS_TOKEN" -X POST http://localhost:8080/osiam-resource-server/Users -d '{"schemas":["urn:scim:schemas:core:2.0:User"],"externalId":"external_id","userName":"arthur","password":"dent"}'"

and this sollution creates user with not defined active field.

Missing logging if authentication/authorization fails

Missing logging if redirect_uri from oauth request does not match the client's redirect_uri in the database.

If the redirect uris do not match, the user is shown a vague error message. In the log files, even on debug level, there is no indication why the login failed.

Request server version

Severity: wishlist

Please add a request that returns the version of the OSIAM auth server that is actually running, including an indication that it’s the OSIAM auth server (to avoid problems like deploying resource server as osiam-auth-server.war caused by a copy/paste mistake). For this reason, please choose a harmonised request path, and make it accessible without auth.

Make session timeout configurable

30 minutes is not enough for most of the use cases. Session timeout MUST be configurable.

Destroy all user http sessions if all user tokens will be revoked

In a single application use case it makes sense to trigger a global user logout by revoke all tokens and simultaneously destroy all http sessions on the auth-server. This can be done by adding the destruction of the http sessions if all user tokens will be revoked.

Switch to YAML configration

Using properties files is not really an optimal way to configure this application. As discussed here, we decided to switch to YAML.

Remove 'scopes' key from access token

The access token has a 'scopes' key which is not needed.

Add new scopes to the example client as a migration

Because two new scopes (ME, ADMIN) were added, we need to provide a flyway migration script to add them to the example client which will be created by default in the first version flyway migration script. I think we should only add the missing ME and ADMIN scope to the example-client, if it exists and not renamed or removed by the operator. If the client isn't existing anymore, the migration will be ignored. right?

Hibernate naming strategy

The default naming strategy of hibernate is the EJB3NamingStrategy. The strategy maps camel case attributes like userName to the column name username. When switching to Spring Boot, the default naming strategy is set by Boot to ImprovedNamingStrategy. This leads to problems with the column names of camel case entity attributes which are not annotated with @Column and a set name parameter (e.g. @column(name = "username") ). I think we should use the ImprovedNamingStrategy before migrate to Spring Boot and add flyway migrations for postgres and mysql to use underscores for mixed case names.

Switch to standalone application

After #24 has been solved, we can move on with the plan and finally switch to a standalone, runnable .jar deployment. This does not contain switching to YAML files, which will be done in a separate step.

Store tokens in the database

Currently, access tokens are stored in an in-memory token store provided by Spring Security OAuth. This has some fundamental flaws, for example:

• Restarting the auth-server revokes all access tokens
• The auth-server cannot be scaled on the x-axis of the scale cube
• We leak state between the individual integration tests which leads to the unpleasant fact that they are not isolated against each other

Especially the last point has given me a hard time yesterday, when I tried to update the ITs for the removal of the old, method-based scopes.

So, I propose that we put the tokens into the database.

Support for public OAuth clients

(Please, see also the previous discussion about this in issue #42)

@ohoho7 pointed out that there's an issue with client authentication:

according to this site:
https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#other-app-types
password grant type, should take only:
username, password, client_id
In your application, passing only those params causing credential error, I do not know where is mistake but I think that passing client-secret is necessary to avoid impersonate client by users...

and

have a look on this quotation from pointed web site:
"The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as Javascript or native apps, then the secret is not used."

The OAuth Spec states in 2.1. Client Types:

OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):

[...]

public
Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.

in 2.3. Client Authentication:

The authorization server MAY establish a client authentication method with public clients. However, the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client.

and in 2.3.1. Client Password:

Clients in possession of a client password MAY use the HTTP Basic authentication scheme as defined in [RFC2617] to authenticate with the authorization server. [...] The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients that were issued a client password.

So, AFAIC authenticating public clients is optional and should not be relied on. But that's not proper represented in OSIAM:

1. OSIAM doesn't distinguish between confidential and public clients
2. OSIAM enforces HTTP Basic authentication even if it's facing a public client

Furthermore there are some edge cases to discuss:

1. If we have a public client, should we make authentication optional or deny the request
2. If we have a confidential client, should authentication be enforced or still be optional

It appears to me, that the OAuth spec is not clear about these points.

Switch to SLF4J for logging

Currently JUL is used.

Internal Server Error on duplicate client registration

When I try to register a client (with the following code) twice, I get an HTTP 500 ISE.

if ! x=$(curl -i -H "Accept: application/json" \
    -H "Content-type: application/json" \
    -H "Authorization: Bearer $tok" -X POST --data-binary @- \
    http://localhost:8080/osiam-auth-server/Client <<EOD
{
  "accessTokenValiditySeconds": "5000",
  "client_secret": "$osiamsecret",
  "grants": [
    "authorization_code",
    "client_credentials",
    "refresh_token",
    "password"
  ],
  "id": "online-registration",
  "implicit": "false",
  "redirectUri": "$verawebserver",
  "refreshTokenValiditySeconds": "5000",
  "scope": [
    "POST",
    "PUT",
    "GET",
    "DELETE",
    "PATCH"
  ],
  "validityInSeconds": "5000"
}
EOD
    ); then
        print -u2 E: cannot register client
        exit 1
fi

I get something back that begins with…

<html><head><title>Apache Tomcat/7.0.28 - Error report</title><style>

… and is basically illegible. The catalina.out logfile contains more information:

ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] - <ERROR: duplicate key value violates unique constraint "uk_c34iilt4h1ln91s9ro8m96hru"
  Detail: Key (id)=(online-registration) already exists.>

I’d have expected an application-level error signalling.

Protect Web Endpoints Against CSRF

Endpoints like access_confirmation, oauth/authorize, etc. should be protected against CSRF. Spring Security has native support for that. First step would be to gather all endpoints that have to be protected.

Build Debian packages in this repo

This repo should contain stuff so that a Debian package can be build. It's still open whether we should use vanilla Debian packaging scripts and stuff, or maybe use the excellent pkg-maven-plugin. I would recommend the pkg-maven-plugin.

Introduce Spring Boot

After #23 has been solved, we can move on with the plan and introduce Spring Boot in the auth-server. This also contains the generation of a standalone, runnable .war file.

Build Docker images in this repo

This repo should contain stuff so that a Docker image can be build. It should be possible to build it as a trusted image on the Hub and also for local testing during development. This can be achieved in the following way:

The install script that runs during the build process checks if there is a locally-built war file in the target folder and uses this. Otherwise it installs Maven, etc. and builds the war itself or downloads it from the central/Sonatype snapshots or something else.

Implement OTP for Two Factor Authentication

Provide the ability to use two factor authentication with OSIAM. It would be a good feature to provide an implementation of OTP as specified in RFC 6238. For a start it might to be a good idea to take a look at GoogleAuth and see how far we can get with that.

Switch to a Spring Boot standalone application with runnable fat JAR

This is the umbrella issue for the transition of this component to a Spring Boot standalone application with an executable fat JAR. See also osiam/osiam#5 for the initial reasons and discussion.

Tasks that have to be done:

• Change Hibernate naming strategy (#13 / PR: #33)
• Switch from xml to java configuration (#23 / PR: #50)
• Introduce Spring Boot, but keep WAR deployment (#24 / PR: #50)
• Switch to YAML configration (#40)
• Switch to standalone application (#25)

Please, maintain this list, if you add new issues or close existing ones.

Deploy to Bintray snapshots with CircleCI

Grant type password response json invalid?

Hi, according to this site:
https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#other-app-types
password grant type, should take only:
username, password, client_id
In your application, passing only those params causing credential error, I do not know where is mistake but I think that passing client-secret is necessary to avoid impersonate client by users...
So, I passed client-secret too and found out that response is:
{"access_token":"71eefd80-2af8-4864-8884-81ff73abd68d","token_type":"bearer","refresh_token":"cb13483b-5fa5-4092-a9a2-1dd4e1a6ca90","expires_in":25594,"scope":"POST PATCH GET DELETE PUT","user_name":"admin","scopes":"POST PATCH GET DELETE PUT ","refresh_token_expires_at":1438343827492,"expires_at":1438286227494,"user_id":"cef9452e-00a9-4cec-a086-d171374ffbef","token_type":"bearer","client_id":"example-client","refresh_token":"cb13483b-5fa5-4092-a9a2-1dd4e1a6ca90","access_token":"71eefd80-2af8-4864-8884-81ff73abd68d"}

Why there are two fields access_token and two fields refresh_token?
Is there some mistake in my configuration or it has to be in that way?

NPE with empty 'active' field for user

Moved from osiam/server#249

@tkrille:

if a user does not contain a value for the field active (i.e. the value is null) the auth-server will throw a NPE. this is caused by this line. when user.isActive() returns null automatic un-boxing will throw the NPE while trying to convert null to a boolean value that is actually needed for the if statement.

the fix is actually very easy but there is one little problem: if there is no value for the field active for a given user, will he be considered active or inactive? i remember that we've had a discussion about this, but i forgot the outcome.

@dacrome:

I think the default should be inactive, because it's mostly how a registration process started where the user has to activate his registration.

@tkrille:

IIRC the resource server will never set the database field to null, so that is only a problem when changing the database manually. you're right that the default value is false, i.e. inactive. nevertheless we should fix this by simply checking for null values.

Add support for listing registered clients.

Currently the org.osiam.auth.oauth_client.ClientManagementController doesn't support to list all registered clients. It would be useful to have such a listing as a foundation for additional admin tools.

OSIAM {auth,resource}-server 2.3 cannot talk to connector4java 1.4

Hi *,

having a minimum requirement of server 2.3 for connector 1.7 is okay, having a minimum required client version for a certain server version is also okay, but if both appear at the same time, the systems need to be upgraded in lockstep, which is not so much okay.

Case in point: VerA.web Online-Anmeldung

ERROR [2015-10-22 17:47:09,502] io.dropwizard.jersey.errors.LoggingExceptionMapper: Error handling a request: 9094fb8c136a34fe
! org.osiam.client.exception.ConflictException: The JSON structure is invalid
! at org.osiam.client.AbstractOsiamService.checkAndHandleResponse(AbstractOsiamService.java:271) ~[vwor.jar:1.6.31.5]

Is it possible? desirable? to have a range of versions that can talk with each other, so that component upgrades need not occur in lockstep (but rather ordered or, even better, arbitrarily)?

Improve handling of parallel requests

Like already did for the 2.x branch, we should improve the handling of parallel request.

Databse connection pooling

It would be beneficiary to the overall performance if we had database connection pools.

misleading error if auth and resource server can’t talk to each other

org.osiam.client.exception.UnauthorizedException: Your token is not valid

This is what an application gets if OSIAM is misconfigured (wrong scheme/hostname/port in all three *.properties files) and the auth server and resource server can’t talk to each other.