Authentication changes in Sitefinity 10.0

Hi all, 

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.  

Could we also think about having this all work seamlessly with an auth provider like Auth0 and JWT support on the services?

This sounds very interesting and promising.  Any way you are changing the way users are tied to a provider such that they could be tied to multiple providers?  You often see this with social media logins, allowing a user to associate their regular account with a social media account or vice versa.

When you talk about integrating with ADFS 2.0/3.0, are you also meaning all functionality will be available such as sliding sessions extending the session in ADFS?  Will it allow for multiple sites to be hosted through one relying party provider or will we need to reconfigure our ADFS to handle multiple relying parties for each site?

Auth0 support out of the box would be awesome :)

Hi Ryan,

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.

Hi George,

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.

Hello.

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.

@Atanas

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.

@Viktor

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.

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.

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.

*EDIT*

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?

Out-of-the-box we will most probably only support JWTs issued by the IdentityServer3. However, we plan to add some extensibility points where you can plug a custom bearer authentication middleware that reads Auth0 JWTs, for example.

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:
"iss": "https://mschneider.auth0.com/", "sub": "auth0|5824b9d6e063032844b33825", "aud": "BshZMBXxC4QfOCec05ykNXd8WLWuLGHY", "exp": 1479111456, "iat": 1479075456
All the claims in the example correspond to Registered Claims Names defined in the JWT specification."

@Steve

Regarding having multiple external providers attached to a single account: How could I know if a user registering via Twitter is the same user who already registered via Facebook, for example?

@Eduardo

Email address is the common thread! :D

@Steve

But I'm wondering what happen if the user didn't use the same email address or didn't set the email address at all (not sure if that's allowed though). It won't be "bullet-proof" :S

Edit:

Yes, the second part of your answer would be the solution, but you can't prevent the user from trying to register a second time with a different social network...

No that's impossible... there's no real way to know if it's them if the email is different... however if it's the SAME, it's CLEARLY the same person and a really just terrible idea by the team to make them different people.

I agree w/ Steve, email's not 100%, but I'd say it captures the majority of users.  Additionally I've seen site that allow you to control which social media accounts you have tied through an account dashboard.

@Ryan

...wonder if anyone is even listening anymore, likely (from above) its already been decided on and we're just talking to ourselves :/  

Yeah, it's probably just us here shooting the breeze. I'm sure things have already been moving forward with dev on this.

Hi everyone,

We are still in the discussion, sorry for the delay.

The main reason to take this external login approach is security. The implementation will come with out of the box support for most used third party providers, and also we will provide the possibility to add additional ones. The email uniqueness of the user can be security issue. For example, you have already registered as an administrator in SF site, and somebody knows your email and login with different provider with same email, he/she can gain administrator rights. Yes, most of the third party providers require email confirmation, but we cannot be sure everybody does, especially if you have own implementation. This problem can be solved if there is a kind of confirmation/ dashboard in the user profile, but the things gets a little more complicated as we read more claims during external login (First name, Last name, Profile image).

The second reason to take this approach is the fact that it is not a common case to login with different accounts to single site. Do you really think this case can be useful?

Nevertheless, we will consider all these ideas and we can extend the login functionality after SF 10.0.

Best regards

@Atanas

Feels more like you've decided and are now trying to find crazy ways to justify it :)

The whole thing about knowing your social creds and logging in also exists if you are already linked, it's a paranoid fantasy scenario far outside of the realm of legitimate.  If one is concerned about that they should have 2fa setup on their social accounts anyway.

Yes there is a common case to log in with different accounts, again back to disqus as an example.  They started with no social login, I had a disqus account... then they added social logins so I linked up google.  I log in so infrequently the next time I hit the site I clicked facebook because I couldn't remember which social one I used... turns out I never logged in with FB there before, but because it was the same email, boom... I was logged into my account.

Now if we run that same scenario in Sitefinity I have logged in without the access I expected, and the devs and admins now have to deal with 2 users with the same email account for no good reason, and what, sync my permissions or something... it's insanity.  We're starting this from scratch guys, why not do it the proper way here now the first time.

Also nobody commented on the Auth0 JWT item there above... Auth0 said they are not doing anything fancy or outside of the JWT spec so why would we even need to do anything to support them, it should just work... they are waiting on a response from me, I'd like to provide one if possible.

I agree with most posts above: it's going to be a mess if a single person gets multiple Sitefinity accounts when logging in through social, site specific, etc. We only have site specific accounts at the moment and even now some people create two accounts, e.g. if they forget their password they create a second account instead of resetting their password. It's a mess when they start posting in the forums using two accounts.

If the new login features allow this I sure won't implement it. I do like the option of logging in via social media though.

I agree (again) with Steve on this.  While it's good to have cause of concern for topic as mentioned, it's not much different from what's already in place or like Steve said a connection is already setup.  Personally I think there should only exist one user and that user can use multiple providers.  So a default (DB) user, could be the same as an LDAP user, who could be the same as a social media login.  They would all use the same user in Sitefinity and just allow the user to manage those (if allowed to manager those).  I would think that if you're that concerned about blindly joining accounts into one, then add a verification step that's sent to the user's email (or require admin approval).  If their email is compromised, that's a bigger issue and one that Sitefinity should be concerned about.

I also think it's good to keep the JWT discussion moving and not lost.  It seems that it could be implemented generically and allow middleware/event points that could be used to hook in custom JWT auth via custom 3rd parties.

Oh god... please don't stuff this up Sitefinity.... Do everything Steve talks about above..

And while you're at it, making changes get rid of "Username" concept entirely, and replace with "Email" as primary unique identifying login.  This will support you with multiple auth providers -> 1 SF account, which is very important.

Further, if you let users log in with Social, then attach >1 social account to their SF account, we can investigate exciting ideas like (with their permission) reading their social data and personalising the website with data from Social?

Hi, guys. Some clarification regarding the JWT authentication. 

Different JWT tokens are validated in different ways. For example, the Auth0 token requires 2 different middlewares depending on the way it is signed: with a symmetric or an asymmetric key (reference). The tokens issued by IdentityServer3 work best with IdentityServerBearerTokenAuthentication. So, we want to give the user the ability to add and configure the required middleware depending on which identity provider they are using.

Furthermore, within Sitefinity a Sitefinity user is required to actually perform some actions: edit, delete, etc. Thus, after the JWT is validated we have to map the JWT to the correct Sitefinity user from the database and load its' claims from there. We will try to make the mapping as general as possible or at least provide the user a way to create the mapping himself.

Let me know if it's clearer now or having any other questions.

Hi guys,

First, thanks about the ideas and proposals in this tread. We had some internal discussions about user login variants, and we are now checking the possibility to use emails as login and also internal links to different providers. I will keep you informed when/how will can release this functionality.

Thx even for the discussion guys!

Keep us updated

Hello everyone,

For Sitefinity 10.0, we have decided to go with following login concept:

- Completely remove username when creating new users, only email will be used. We will keep database schema as it is for backwards compatibility.

- When you login, you can use either email address or username. The username login is needed for already created projects which migrate to the new version.

- Email duplicates will be forbidden as they are used as usernames (only for new users). It will not be possible to change the email once created.

- External provider logins (Facebook, Google, ADFS, ect.) will use email claim to identify the user, and map it to existing user with the same e-mail. If the user is not existing, new one will be created with predefined user roles from administrator.

- In this version, we don't plan to implement external provider dashboard for the user. Maybe this will be done in the future.

I think this approach covers the requests from this thread. Any additional comments or notes are welcome.

This is great news, very exciting!

But, there is 1 thing still not right...

It will not be possible to change the email once created.

You definitely have to find a way to allow this to work!  One solution may involve storing the Username as GUID, and modifying Login controls to query Email field instead of Username.

OR, what we have done sometimes, a 2 step login process:

1) var userFound = (Lookup user by email typed in)

2) If match, perform login with userFound.UserName, password typed in

[quote]Atanas said:

It will not be possible to change the email once created.
[/quote]

Am I reading that correctly?  You're not going to allow a user to change their email after they have an account in the system?  If I understood that correctly, that's a huge stumbling block.  Email should be unique in the system and you should be identified by email address, but it shouldn't be readonly.

Can you provide more clarification on that point, if we're understanding you properly and if so the reasons why that was chosen?

What would the technical reason be for that?  If the username is just an entry in the DB, the UserId is the important part...?

That's unacceptable indeed. It will force users to create a new account if their e-mail changes, and loose all account history (in our case at least forum post history).

One person should have one account only, and there should be no reason, ever, to create a new account.

[quote]Atanas said:

The second reason to take this approach is the fact that it is not a common case to login with different accounts to single site. Do you really think this case can be useful? 

[/quote]

We just redesigned our login system for several reasons

1. We had multiple accounts with the same email and different login methods. Many of our users would log in with twitter one day, yahoo the next, google and facebook and them create a local account. I don't think this was intentional in all cases as people just forgot if it was google or facebook login they used.

2. We were using openID 2.0 and wanted to modernize our accounts.

3. We wanted to integrate with sitefinity better.

We ended up building an identityserver3 server that support google, facebook, twitter and local accounts and all our apps use owin  OpenIdConnectAuthentication() with some custom patches (there are bugs in the way it manages cookies).

The plan was to deploy a man in the middle STS that translated from OpenID connect so having this built into 10.0 means I will leave this integration point out till later.

The big stumbling point is if the new system will pull common fields like email (it's all we collect) so users can sign up for sitefinity newsletters and such without retyping their email.

As for trusting providers, google will tell you if it has verified the email. Facebook will not let you log into other sites until you verify. Twitter doesn't provide an email so we let them log in and then block them until they click a link in the email. 

The issue we are typing to solve still is how to allow AD authentication for the admin but social for the front end.

How did you solve the issue where there are conflicts

user 1:

username(not email) : email2@example.com

email: email1@example.com

password: password

user 2:

username: email1@example.com

email: email2@example.com

password: password

So someone shows up and enters email1@example.com and password. Who just logged in? We actually had this case in our user database.

My solution was to trow out all the usernames and passwords (our old database has a hash that can be brute forced with a bitcoin farming machine) and force a password reset based on email when the user next came back.

Hello,

We did some research this week about email/username change and we decided to allow this operation. We will keep username and email always sync in the database for new/updated users.

Username will be removed as parameter and only email will be used at API level. The username property will still be available and API will take care that it will always be synced with the email.

All backend user and profile pages will contain only email field.

@Jeff: Here is the algorithm that we will use for login:

1) Check input email/username field in the DB. If only one user with this email exists, then use it for login. If not, then:

2) Check input email/username field in the DB. If there is no such email in the db, check in the username filed. If such user is found, use it for login. If not, then:

3) If no username or email exists in the db, return invalid user/pass error.

4) If more than 1 email exists in the email field in the DB, return error.

So Jeff, in your case, user 1 will login.

Great choice!  Thank you

Agreed, thx for listening team, excited about this!

Hello everyone,

We have shared previously the plans for Sitefinity 10.0 -

• The authentication will continue to support both email and username 
• Registration of new users will be with email only (the username will be filled automatically with the email in the database).

There is a question to everyone:

Are there any requirements for user registration with username and not email? No matter if those are past or future projects.

Thanks in advance for your feedback.

I have never had the requirement for a site to have username and not email... 100% of the time (here) we have to hack in making the email the username (or visa versa)  in an event or overriding a widget or something.

So we don't register users - so not sure it'll matter, but all of our users come from our AD integration.  That has a distinct separation between Username and Email.  How will the new process handle the mapping of the fields in an LDAP/AD integration?  Will the search process change on the User screens as well? 

Hi gyus,

There is some update for email change functionality, which will be implemented in Sitefinity 10.0.

- Email change will be possible only for internal users (the ones, first registered with email/password). Email change should also be confirmed with the user password!

- Email change will not be possible for external users (the ones, first registered with external provider). Reason for that is that email is external key to the provider, and if changed, the account will no longer be accessible.

Will the authentication changes in Sitefinity 10 support IdentityServer4 upon release or at some point in the near future?

Hi Craig,

Sitefinity 10 will not support IdentityServer4 as it targets ASP.NET Core.

Basically, IdentityServer3 and IdentityServer4 have same functionality, the difference is the target platform.

What are the steps site owners need to take when upgrading to version 10? Like changing the login screen, account creation page, account edit page, etc.

We have a solution where we have an external identity provider running Identity Server 4 for the organization.  We are currently setting up a new site using Sitefinity 10.  What is not very clear is how to configure Sitefinity to leverage an external Identity Server implementation.