Best practice for Content Delivery in relation to databases

Question

In a client's environment, a user login in will be added a role in order to have access to secured content.

This mean that during the login operation, the user itself will be modified and saved. Under the cover, the user.Profile.Save() operation will be performed.

At the system level, the save will write in the Core database, and this is where I am a bit skeptical. I feel like the Core and Web Databases should only be read from a CD server.

Is it possible to send a command to the CM server to do the save? Or should my client use another way to give rights to a user?

I must confess that security scaling is not my cup of tea so if someone could enlighten me.

Cheers,
Simon

Answer 1

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 extranet/Anonymous User

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:

1. 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 <domain>/Anonymous). The 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.
2. 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.
3. 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 extranet/<username> account.
4. 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
• 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 extranet/Everyone and default/Everyone roles. This means that you can assign securities that will apply to all users - Authenticated or Anonymous - to the extranet/Everyone or 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 default/Everyone and 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 Anonymous Users.

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 domain
• 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/Member and 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.

1. Create an extranet/Member security role (or a <domain>/Member role if you're not using the extranet domain)
2. Create an extranet/Unauthenticated security role (same comment as 1)
3. Edit the extranet/Anonymous user in the User Manager, and assign it the new extranet/Anonymous role.
4. 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 extranet/Anonymous role.

Answer 2

although you could associate a role to an user at login time(not sure if this is a requirement of yours) but you can also have an extranet authenticated role with proper permissions already set and have that role assigned to the user. All that user has to do is actually authenticate and you display the content for that user based on the permissions of this role.

Another option you would get is using virtual users and set the roles at login time just as this example shows