Is Saving/Updating Data from a CD Against Best Practices?
Saving security/access changes from a CD is acceptable, and doesn't violate best practices.
Saving data from a CD in general also doesn't violate best practices, so long as you are mindful of the data that you are saving, where it will be saved to, and that it can be overwritten (effectively deleted) on publish if saving to the Web database.
All in all, so long as your code/logic does not open create a vulnerability where users saving data to the Web or Core databases have the ability to inject code, directly manipulate security roles or do other things of that nature that would be clear security issues, saving any kind of data from a CD is acceptable.
Desired Logic Breakdown
Addressing the core of your question, I think you may be overthinking your securities a little bit. Given the situation that you described, you shouldn't need to make any changes to the user on login - that should all be done for you, thanks to Sitecore's "security authentication model".
Before we dive into the securities, let's take a step back and consider the followin breakdown of the logic that you are looking to support (described in the OP):
- Site visitors can be categorized as either Authenticated Users or Anonymous Users, where an Authenticated User is a visitor that has successfully logged into the site and an Anonymous User is visiting the site but has not logged in
- The Authenticated Users should have access to visit "member-only" pages and/or view "member-only" content that Anonymous Users cannot access
- Sitecore securities/access rights should be used to ensure that visitors have access to the content they are supposed to have access to, e.g. Authenticated Users have access to "member-only" content and "guest" content, while Anonymous Users only have access to "guest" content.
Keep the above in mind, as we review how Sitecore's authentication model and roles work. Leveraging Sitecore's authentication model, the above is a pretty straight-forward use of Sitecore's security featues.
Sitecore's Authentication Model and the
If you are using Sitecore membership - which I assume you are or are, at the very least, tying into since you want to control page/content access with Sitecore roles and access rights - then the way that Sitecore's authentication model works is as follows:
- A visitor browses to the site and a new session is started. Since this is the first visit for the current session, Sitecore doesn't know "who" the visitor is (username, etc.), so Sitecore "logs the user in" (behind the scenes) as the
extranet/Anonymous user (note that if you have custom domains, then the user will be
extranet/Anonymous user is a special user account that Sitecore creates (by default) for each security domain that you configure. This user account is meant to identify the "unidentified" users, and has no roles, by default. You may assign custom roles to it as needed.
- Sitecore now needs to check the security settings of the page that the user - whom Sitecore now knows as the
extranet/Anonymous user - requested/tried to browse to, in order to verify that the user has access to view the requested page. If the user does have read access to the page, the user is shown the page; otherwise the user is redirected with an "unauthorized" status.
- Assume that the visitor now navigates to your site's login page and authenticates, either by creating a new account or by logging into an existing one. Sitecore now knows "who" the user is, and so the user is effectively assigned the appropriate profile, security roles, etc. (note that no actual assignment happens at this step; this description is meant for visualization purposes, only; the users profile, roles, etc. will have already been set on the user account that the visitor is logging into). This means that the user is effectively logged out of the
extranet/Anonymous user account and logged into the
- Assume that the visitor now logs out. The visitor is then effectively logged back in as the
extranet/Anonymous user, and the cycle repeats.
Authenticated Users vs Anonymous Users
Given what we now know about the Sitecore authentication model, we can make the following inferences about Authenticated and Anonymous Users, and their involvement in the authentication model itself:
- Before logging in, all visitors on the site are, by default, effectively logged in as the
extranet/Anonymous user has no roles, by default, or only the exact set that you define, if you decide to add roles to it
- On logging in, the visitor is effectively disassociated from the
extranet/Anonymous user and associated with the user account that they are logging into. Any security roles, etc. that the visitor had as the
extranet/Anonymous are removed from the visitor, and the security roles, etc. from the user account that the visitor logged into are assumed/"added to the visitor" instead.
- Although the
extranet/Anonymous user has no roles by default, it is automatically a member of the
default/Everyone roles. This means that you can assign securities that will apply to all users - Authenticated or Anonymous - to the
default/Everyone roles, and securities that should apply only to Anonymous Users can be assigned to the
extranet/Anonymous user account or to a custom role that is added to the
extranet/Anonymous user account (better-practice, IMHO).
Using the Above to Architect Your Authentication Logic Flow
Given what we now know about how Sitecore's authentication model works, how the
extranet/Everyone roles work, and how the
extranet/Anonymous user works and how it differs from other user accounts, all we are missing is a couple of roles to differentiate our
Authenticated Users from our
Solution - Part 1 - Detailed Breakdown of Required Roles and their Use
Based on what we have learned, the following are all of the security roles that you currently have and/or will want to create and use to control the security settings for our site visitors:
default/Everyone - Built-in - only make changes to this role when you wish to apply security settings to all users on all security domains; all users, including content authors and other Sitecore users, have this role as well
extranet/Everyone - Built-in - an
Everyone role is automatically created for each domain; make changes to this role when you wish to apply security settings to all users on the domain (the
extranet domain applies to the
website site, by default)
extranet/Member - Custom - make changes to this role when you want to apply security settings to Authenticated Users on the
extranet/Unauthenticated - Custom - make changes to this role when you want to apply security settings to Anonymous Users on the
extranet domain (this is just here because I don't like making changes to the
extranet/Anonymous user, directly)
Note that there are two custom roles listed in the above, and they will require a little additional effort:
extranet/Unauthenticated. Once we have these roles implemented, we shouldn't need to do anything else to satisfy the requirements given and to be able to assign different security settings to Authenticated and Anonymous users.
Solution - Part 2 - Implementing the Custom Roles
The following four steps are all you will need in order to satisfy the requirements. Steps 1-3 can be preformed entirely in Sitecore.
- Create an
extranet/Member security role (or a
<domain>/Member role if you're not using the
- Create an
extranet/Unauthenticated security role (same comment as 1)
- Edit the
extranet/Anonymous user in the User Manager, and assign it the new
- On user account creation, each user account will be assigned the
extranet/Member role. This is a one-time action that only happens at user-registration time, meaning that you do not need to manually add or remove roles to change the securities/access rights of the visitor each time they log in. All changes will automatically be applied, as the user will have the
extranet/Member role and will no longer have the