With version 10.0 due to end of February 2017, we are doing important changes in the authentication mechanisms that Sitefinity currently has. These are going to be substantial improvements – we will provide out of the box integration with external authentication providers that support OpenID connect and Oauth2. We’ll provide integration with IdentityServer3. Moreover, ADFS 2.0/3.0 will be supported out of the box. We’ll also provide support for Social logins (Facebook, Twitter, Google+ and more). We plan to open extensibility points allowing you to plug in or change the authentication providers (e.g. OWIN integration just as an example).
These improvements were pre-requisite for us to move forward with .NET4.6 and beyond ..
The old approach for authentication relying on the Simple Web Tokens (for clients/APIs that already have implementation for it) will be supported and we work on ensuring maximum backward compatibility, but there’s still possibility that we bring breaking changes in the authentication API, as the changes are quite big.
I and the development team behind this task will be open for any questions that you might have in the matter above. We’d be more than happy to discuss your current 3rd party integrations, single sign on scenarios or anything else you may have customized/implemented for your projects in regards of authentication. It’s of our interest to support as much scenarios as possible, thus making the transition to 10.0 as smooth as possible.
There are currently no plans for the Auth0 support, but we will look into it.
Regarding the services, we will support bearer token authentication. We are still discussing which services to be allowed to use bearer tokens, whether to use different scopes for different services, what to be configurable and what not. Thus, any feedback regarding that matter would be greatly appreciated.
With new authentication, the Administrators can assign how specific provider is mapped to internal role in Sitefinity (ex. all Facebook users can be set to Frontend users). It is not needed to have internal account when you first login with external provider, the account is automatically created and stored internally on first login. The assumption is that one external account is linked directly to specific internal account, so it will not be possible to have multiple external provider accounts assigned. This gives more flexibility to change roles or permissions to already registered users.
As ADFS relaying party, we will have 2 main configuration parameters in Sitefinity - wtrealm (Relaying Party name) and link to metadata address of the server. These configuration parameters can be the same for several Sitefinity sites, but the ADFS server should distinguish where to send the data token, i.e. the endpoint of the relying party. If you specify several endpoints, then it should not be a problem to use one relying party configuration for several Sitefinity sites.
For each ADFS user, we create internal Sitefinity user. The login expiration time depends on a local cookie for this user, not the one from ADFS server. Therefore, we do not plan to implement sliding sessions extending in ADFS. The local expiration time can be configured in Sitefinity, and if it expires, the user has to login again.
I agree with Steve on all his points. A user is a user no matter how that user logs in (SF default, Social, LDAP) as long as there's some sort of mapping. If I sign in with my Google account, but then use my Twitter account, it should be the same SF account not two SF accounts.
Additonally, JWT would be awesome to use and could make supporting other non-out-of-the-box authentication providers much easier.
Mulitple external providers attached to a single account really is how (afaik) the current system works, and it's great. I'm not sure why it would be better to have a single user with multiple accounts... "Dan" is still "Dan" even if he logs in from Facebook or Google, or SF direct.
Fair enough, I mean it's best of breed for social auth, every provider on the planet... HOWEVER just supporting JWT on the service layer would be a huge bonus for us as we could Auth0 in the NativeScript apps, get the JWT token, then just send to request to Sitefinitys WebApi layer with no extra work...
Right now we have to wire up custom Attributes and create custom ServiceStack services to send all the requests through, all the hard OData work you guys did is just useless to us right now.
JWT is like the gold standard, it would be a shame to just ignore when we're basically planning a re-write (or re-jiggering) here... like building WCF again when WebApi is available.
Should note that I find the idea of a usecase where I would need to permission based on external provider wayyyyy more obscure than just based on user... does anyone even do per provider based permissions? I feel like it'd be a massive PITA not be "more flexible"... are we being sold it's "flexability" because it's already been designed and developed this way and there's no changing it now?
Just a little confused by your response...are you saying that you will be supporting JWT with provider specific implementation (IdentityServer3 and Auth0)? Or are you saying that you'll be implementing JWT generically and extensible by means of middleware (that IdentityServer3 and Auth0 will be using)?
I'm confused as well... Auth 0 confirms to the jwt spec, it's not custom...?
I pinged auth0 on the matter and this is what they had to say
"While JTWs allow for customization, we adhere to the standard fields when it comes to authentication purposes. As an example, one of our JWTs payload looks like this:
All the claims in the example correspond to Registered Claims Names defined in the JWT specification."