Use Flyway to manage the schema change

Upgrade the database is challenging.  Data may be already there while you are introducing the schema change.

The base schema may be different.  New customers start from scratch with an empty database.
Existing customers may be at the different patching levels and thus require different "ALTER script" to change the schema.

Flyway is not the most advanced system I have seen and it does meet all my expectations, but it is a helpful tool to manage this schema migration problem.

OpenSAML

To make an application as a service provider (SP), you need to support SAML protocol.

It includes accepting the SAML message and generate the SAML message.

This API seems help the developers to hanlde SAML

OpenSAML2 User Manual

Here are examples:

SAML and SaaS

SAML is an important standard used in the SaaS world.

Scenario before SAML

Traditionally, the user and password need to be created in the service provider.
The cloud service provider need to maintain the users.

If a user leave the company, we no longer want the user to be able to access the cloud service.
The problem is that the administrator within the company may not be aware or may not have the visibility or the control over the user store in the cloud service.

Remember that the client company may use multiple services.  The IT administrator in the client company will need to keep track all the services that the user has access and figure out how to get the user out of the systems.

The IT administrator really wants to have one switch to turn off all the access.

The things become more complicate as the user may just change the job role, and the IT administrator may need to change the permissions granted to the user in each of the service the user has access to.

If the cloud service does not integrate with the client company's IT system, the entire system won't flow very well.

--

Understand Single SIgn On

Here are my notes.

1. The sign on process protects the software and the data stored within or accessible by the software. from unauthorized access.
2. The sign on process is to ask the user to provide something, such as password, to verify himself.  Only those people who have the right answer is allowed to get in
3. SSO, from user perspective, is about using the same sign on password and sessions for multiple applications.
• SSO allows the users to not remember multiple passwords.
• SSO can be used to avoid the user to provide the same thing over again (within a browser or even across browser)
4. SSO, technically speaking, is to by pass the login screen from the applications and use a login screen from the SSO server.
• Once the SSO is enabled, the application login page should not be seen by the users.
5. SSO allows the user information (password) used for authenticating the user to stored centrally, not in each apps.  The sensitive information can thus be protected.
6. However, applications can ask the SSO server to provide additional attributes about the users
7. The login page redirection from the apps to SSO server is a typically way to enable SSO.
• If the SSO server is also providing a portal service, in the other word, the applications are listed centrally, the redirection from an application URL may not be important.
• We cannot avoid the users to use a browser bookmark to access to the application.  Redirection from the apps to SSO is almost always required.  Also.  It may be from any page, not just the specific login page
8. Browser Cookie is a way to make the browser to "remember".  It is used to communicate between the SSO server and the apps. 

Here are notes about SAML:

SaaS vs Custom Sotfware Hosting

Software as a service means that you, as a client, do not need to install and deploy software.  You can just use your browser to access your application.  On premise deployment, on the other hand, means that you have to deal with installation, deployment, and customization yourselves. I recently learned a new type of software hosting service for on-premise deployments.

The service is exactly focusing on the pain point, dealing the customization of the software.  

Even for the software you deployed on premise, nowadays you can get the standard software from the software vendors online.  The installation and upgrade can be handled already via some automation.  However, the software package you get is still the standard software like everyone else has.

The new concept is that the customized software and configuration information are stored in the service provider.  You never really customize the software yourselves.  Instead, the service company provides the customized software for you.  The software you have is kind of a branch of the standard software and maintained by the service provider.  Also, the configuration files or metadata are deployed from the testing instance that the service hosted.  You are the client of the service provider and they maintain your software packages for you.  However, when it comes to deployment, you still have it in your facilities and still inside your firewall.