Refactoring of the providers and cleanup

[akkie]

The providers do handle the Identity not any more. They return only the LoginInfo and for the social providers the SocialProfile which contains the LoginInfo and the profile data returned by the provider. I followed your suggestions for the Identity trait. It contains only the LoginInfo. The authentication information (secret tokens, password, ...) will only be handled by the providers. I have created an AuthInfoService` which can persist this data into the backing store.

With the current implementation the authentication flow should be as follow.

Social Providers:

If the user authenticates the first time, the social provider implementation stores the authentication info for the linked LoginInfo into the backing store and returns the SocialProfile. Now the controller should create a new Identity. Maybe only from the data provided by the social provider or with additional data(IP-Address, UserAgent, Lang, ...). It the user authenticates again at a later time, then the provider updates the authentication info for the linked LoginInfo and returns also the SocialProfile. Now the identity can be updated with the returned profile data and the LoginInfo can be stored in the authenticator cookie.

Credentials Provider:

During registration the registration controller stores the authentication info and the created Identity in the backing store. Now if the user tries to authenticate with its credentials, the provider checks if the stored authentication info matches with the credentials. If so the provider returns only the LoginInfo which can then be stored in the authenticator cookie.

[fernandoacorreia]

Awesome! That sounds great. I'll review the commit.

[fernandoacorreia]

Should be val MD5 = ... since we're capitalizing acronyms.

[fernandoacorreia]

Excellent work. Things are getting both simpler and more flexible.