iVIS uses OAuth 2.0 protocol (implemented by standard Spring Security provider). iVIS is identity provider for any client application that uses it. It means that if user wants to use some iVIS client application he has to login on iVIS (and receive token in the background). It works the same way as popular social networks. In addition, iVIS can use third-party identity providers too. So user after he is redirected to the iVIS login page may choose the option to login using BankId for example.
Each user has to be registered in iVIS and obtain some permissions from iVIS administration before he can use the system and any of it’s client applications. To become a registered user you need to fill out the form on http://ivis.dev.imcode.com/registration. After that you will have your username and password. All passwords are stored as bcrypt hashes so they can’t be read.
While the login username and password from the login page is sent over HTTPS connection using the SSL encryption (if SSL certificate is installed; note: it is not installed on the dev iVIS Server).
Allowed users actions set is controlled as intersection of client and user permissions. So each iVIS client application has set of permissions (defined by the iVIS system administrators). User have permissions defined by administrators either. So the resulting user permissions in the given client is intersection of client and user permissions. For example, if the client has permissions to use resource A, B and C and the user has permissions for the resources B, C and D, resulting user permissions using the given client is B and C.
Permission is access to the given API action or some piece of data, it is controlled on the low level of the iVIS API.
Currently data in the iVIS database is stored as plain text, without encryption.
iVIS handles the errors on 5 stages:
- Validation errors.
- Database level errors.
- JSON/XML mapping errors.
- Security errors.
- Other errors.
Handling and providing corresponding messages about missing required fields, too long text values etc.
Validation works on both sides (client and server). On client powered by jQuery Validation Plugin. On server powered by Spring Validator interface. Validation use cases in details described here.
Database level errors¶
Handling and providing corresponding messages about database level errors, like missing values with the given key etc.
JSON/XML mapping errors¶
Missing or extra fields etc.
Expired or invalid tokens etc.
All other errors.
More about OAuth 2.0 implementation¶
There are two main entities in the iVIS OAuth 2.0 implementation: AccessToken and RefreshToken. Their classes are mapped on the corresponding tables:
The provider role in OAuth 2.0 is actually split between Authorization Service and Resource Service, and these reside in the iVIS with Spring Security OAuth. The requests for the tokens are handled by Spring MVC controller endpoints, and access to protected resources is handled by standard Spring Security request filters. The following endpoints are required in the Spring Security filter chain in order to implement OAuth 2.0 Authorization Server:
- Authorization Endpoint is used to service requests for authorization (URL: /oauth/authorize)
- Token Endpoint is used to service requests for access token (URL: /oauth/token)
You can find details here.