+1-888-365-2779
Try Now
More in this section

Forums / Upcoming Features / Authentication changes in Sitefinity 10.0

Authentication changes in Sitefinity 10.0

39 posts, 0 answered
  1. Georgi
    Georgi  avatar
    1 posts
    Registered:
    18 Feb 2008
    28 Oct
    Link to this post

    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.  

  2. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    28 Oct
    Link to this post
    Could we also think about having this all work seamlessly with an auth provider like Auth0 and JWT support on the services?
  3. Ryan
    Ryan avatar
    6 posts
    Registered:
    20 Nov 2012
    31 Oct
    Link to this post
    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.
  4. George
    George avatar
    17 posts
    Registered:
    16 Jan 2014
    31 Oct in reply to Georgi
    Link to this post
    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?
  5. Eduardo
    Eduardo avatar
    3 posts
    Registered:
    10 Dec 2013
    02 Nov in reply to Steve
    Link to this post
    Auth0 support out of the box would be awesome :)
  6. Atanas
    Atanas avatar
    0 posts
    Registered:
    07 Nov 2016
    07 Nov in reply to Ryan
    Link to this post

    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.

  7. Atanas
    Atanas avatar
    0 posts
    Registered:
    07 Nov 2016
    07 Nov in reply to George
    Link to this post

    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.

  8. Viktor
    Viktor avatar
    0 posts
    Registered:
    07 Nov 2016
    07 Nov in reply to Steve
    Link to this post

    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.

  9. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    07 Nov
    Link to this post

    @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.

  10. Ryan
    Ryan avatar
    6 posts
    Registered:
    20 Nov 2012
    07 Nov in reply to Steve
    Link to this post

    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.

  11. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    07 Nov
    Link to this post

    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?

  12. Viktor
    Viktor avatar
    0 posts
    Registered:
    07 Nov 2016
    08 Nov in reply to Steve
    Link to this post
    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.
  13. Ryan
    Ryan avatar
    6 posts
    Registered:
    20 Nov 2012
    08 Nov in reply to Viktor
    Link to this post

    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)?

  14. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    13 Nov in reply to Ryan
    Link to this post

    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."

  15. Eduardo
    Eduardo avatar
    3 posts
    Registered:
    10 Dec 2013
    14 Nov in reply to Steve
    Link to this post

    @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?

  16. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    14 Nov
    Link to this post

    @Eduardo

    Email address is the common thread! :D

    I think disqus or something has an option when logged in to link up your other social accounts as well, this would be good for Sitefinity to impliment as well (if the email DOESN'T match)... it'd just be something in the profile widget.
  17. Eduardo
    Eduardo avatar
    3 posts
    Registered:
    10 Dec 2013
    14 Nov in reply to Steve
    Link to this post

    @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...

  18. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    14 Nov in reply to Eduardo
    Link to this post
    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.
  19. Ryan
    Ryan avatar
    6 posts
    Registered:
    20 Nov 2012
    14 Nov
    Link to this post
    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.
  20. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    14 Nov
    Link to this post

    @Ryan

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

  21. Ryan
    Ryan avatar
    6 posts
    Registered:
    20 Nov 2012
    14 Nov in reply to Steve
    Link to this post
    Yeah, it's probably just us here shooting the breeze. I'm sure things have already been moving forward with dev on this.
  22. Atanas
    Atanas avatar
    0 posts
    Registered:
    14 Jun 2014
    16 Nov
    Link to this post

    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

     

     

  23. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    16 Nov in reply to Atanas
    Link to this post

    @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.

  24. Arno
    Arno avatar
    249 posts
    Registered:
    08 Sep 2010
    16 Nov in reply to Steve
    Link to this post

    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.

  25. Ryan
    Ryan avatar
    6 posts
    Registered:
    20 Nov 2012
    16 Nov
    Link to this post

    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.

  26. Stephen2
    Stephen2 avatar
    94 posts
    Registered:
    05 Feb 2012
    16 Nov
    Link to this post

    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?

  27. Viktor
    Viktor avatar
    0 posts
    Registered:
    07 Nov 2016
    17 Nov
    Link to this post

    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.

  28. Atanas
    Atanas avatar
    0 posts
    Registered:
    08 Jul 2016
    18 Nov
    Link to this post

    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.

  29. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    23 Nov in reply to Atanas
    Link to this post

    Thx even for the discussion guys!

    Keep us updated

  30. Atanas
    Atanas avatar
    0 posts
    Registered:
    08 Jul 2016
    23 Nov
    Link to this post

    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.

39 posts, 0 answered
1 2