Standard extranet/intranet authentication
In this section we'll go over the most basic type of authentication available on every site.
Making pages that require authentication
If you put an entire site or a branch into a specific asset class and then set the permissions on that asset class such that 'all other users' has no read access then by definition all assets under that class will require some form of credentials input before access to that asset is given. If there's no login customisation in place then the default 'challenge' will be presented to the end user.
Default authentication
If no other settings are put in place and an extranet or some form of authentication is required then the CMS will do the following
- Put up the site with the default username and password challenge in place of the content layout (so the navigation and header and footer are still visible)
- Users entering their credentials will be looked up in the database and the group they belong to will be identified.
- If any of their groups has read access on the asset(s) in question then the asset will delivered to them.
Behaviour on access denial can be hard to predict, in the event of it being a simple file download normally an 'access denied' text is presented. For pages a defualt message and the relevant login screen is returned. However it's possible to serve a page but have no access to the files or images on that page which would make predicting the resulting page output difficult.
Users/members
Extranet/intranet users can be added one by one to the Sitekit database and assigned to a group. If the relevant users are not added then no access is given.
Additionally the CMS has options to allow you to bulk upload user to the CMS via a desktop tool so you can use a CSV file as the source for the data.