Rock security

Rock supports a flexible security system that can be used for both object level security and/or entity-type based security. The framework's security can be thought to work like this:

1. First, authorization is checked for the particular entity instance.
2. If no authorization rules/records were found, then the entity's ParentAuthority property is used to check for authorization.

Example Security Walk-through

Let's consider the 'page security' example to help illustrate this mechanism. When determining whether or not a person has access to view a page, the page's security is checked, followed by it's parent page (which is a page's ParentAuthority), etc. up to the root page. However if a page does not have a parent page (ie, it is a root-level page) the Page entity class defines the ParentAuthority as the page's Layout.Site (shown below).

ParentAuthority

By overriding the ParentAuthority in your custom Entity class, you can control what will be used when the framework checks for authorization (if no authorization exists for the object/instance). For example, looking at Rock's Model\Group.cs class we can see that a Group's ParentAuthority is first its parent group (if one exists) otherwise it falls back use its GroupType:

    public override Security.ISecured ParentAuthority
    {
        get
        {
            if ( this.ParentGroup != null )
            {
                return this.ParentGroup;
            }
            else
            {
                return this.GroupType;
            }
        }
    }

Similarly, as mentioned above, the Page class defines the ParentAuthority as the page's Layout.Site if it has no parent page:

    public override Security.ISecured ParentAuthority
    {
        get
        {
            return ( this.ParentPage != null )
            {
                return this.ParentPage;
            }
            else
            {
                return this.Layout.Site;
            }
        }
    }

Person Identification Without Authentication

Person impersonation provides a way to for a user to be identified through a unique url parameter. This means that urls can be generated that link to a Rock instance and contain an identifier that will identify (not authenticate) the user without them having to create an account or login. For example, users receive an email asking them for their t-shirt size and after clicking on the provided link, they are taken to a particular landing page. Rock identifies the unique person and a block prompts them for their t-shirt size and and then stores it.

The Person object now has a read-only property called "ImpersonationParameter." This will return a parameter name and value string that can be added to a generated URL (the parameter name is always rckipid).

Whenever a Rock page is requested and the rckipid url parameter is included, Rock will evaluate the parameter and set the CurrentUser to a dynamic user record associated with the person that the value belongs to.

The User object has a IsAuthenticated property that will be false if the current user was set by the rckipid parameter. IsAuthenticated will be true only if the user actually logged in (was authenticated).

It is important to evaluate the IsAuthenticated property of the CurrentUser if an action requires that the user has actually logged in. For example, the LoginStatus.ascx block will only display the "My Account" link if the current user is authenticated.