Reference library

Sitekit CMS Help» Reference library» Authentication
Article number: 304314

Authentication

Appropriate secure and usable authentication is a key aspect of any CMS. Authentication we define as being 'a system that verifies the identity of a User who wishes to access it.' For a CMS there's two areas where its implemented. The administration system need authentication and also any extranet area of a large site or an intranet site itself also needs authentication. This page and its sub pages will summarise and give details on all aspects of authentication used in Sitekit. It will also provide links to the online help pages specific details on the relevant dialog boxes and site settings are. This document has been rewritten and revised for CMS 10.2 as this version has added substantial new code to support syndication and also support for AD integration in Windows Integrated authentication (WIA environments)

For the sake of completeness we'll deal firstly and briefly with the administration system and then go over the variants needed for extranet and intranet authentication.

Access and authentication in the CMS administration system.

The authentication system is accessed by a simple username and password combination with the username and encrypted password stored in the Sitekit database itself. No externalisation of this system is possible. The administration user is always challenged via the customisable admin login screen and the login screen is served over https to protect any passed in credentials from 'packet sniffing' techniques. Any administrator passwords or any password mentioned in this page any of the other authentication pages mentioned here are stored on the database server in an encrypted way. Sitekit sysadmins can reset users credentials but they cannot read any user passwords. The admin system adopts this approach from OWASP in order to protect itself from brute force attacks. At the same time it logs and stores in the audit trail login attempts successful and unsuccessful. There are various protection elements put in place for locking accounts in the face of log ins on different devices (added in 10.5), this is in line with  CESG advice

Extranet authentication methods

Many customers have a requirement for large numbers of staff to log into Sitekit CMS, but wish to avoid the twin problems of having to create an equally large number of Sitekit CMS Users, and then coping with the correspondingly large number of forgotten passwords. Sitekit offer several ways of doing this outlined below. Each of these approaches are detailed on separate pages below

Very few of the above methods can be implemented by sitekit alone. Many are only applicable to deployed solution inside firewalls or other mote complex setup. Where this is the case a strong partnership and agreement needs to be formed between Sitekit and the relevant infrastructure provider to get these to work.

Nomenclature

There's a lot of acronyms, technical expressions and set phrases associated with authentication. For the sake of clarity sitekit try to consistently use the following

  • Network credentials - these are the username and password that most users employ on a daily basis to log on to their computer when they start work. They're often held and managed by Active Directory.
  • Challenged/unchallenged - this is when the web site you're trying to access put up a screen or popup and asks/challenges you for you credentials, it won't give you access to any of the site till it gets the right ones. Conversely, unchallenged means you get access to the site without that bother. Some unchallenged lets you in but you are an anonymous user
  • Single sign on - The accepted definition for this is that a user logs into the machine in the morning using their network credentials and then is not challenged (see above) on subsequent access to their site. However there's a lot of confusion between this and same sign on below so it usually best to spell out your requirements.
  • Seamless sign on - same as the above
  • Same sign on - this is where a user logs into the machine in the morning using their network credentials. When they try to access their site later on in the day they are challenged for their credentials however the can use their same network credential in order to gain that acces. This is advantageous as it prevents them from needing another password.
  • Anonymous access - Some authentication methods allow you to get into a site but the site doesn't know who you are. This can be OK but is not workable if you subsequently want that user to comment on pages or post on forums or offer personalisation.
  • Multiple groups - the CMS allows user to be members of multiple groups to provide good access control. Some of the authentication methods outline support authentication but are unable to map the authenticated user to multiple group so instead they maps them to their master group
  • Active directory (AD) - Almost ubiquitous directory service that Microsoft developed for Windows networks that is included in most Windows Server operating systems as a set of processes and services. AD authenticates and authorizes all users and computers in a Windows network assigning and enforcing security policies for all computers on that network.
  • Lightweight directory access protocol (LDAP) - an industry standard protocol for accessing and maintaining directory information services. Sitekit will use LDAP to return the relevant users from an AD to decide who gets access.
  • Windows integrated authentication (WIA or IWA) - automatically authenticated connections between Microsoft services and directories

There's a lot more some of which are defined on the relevant authentication pages above.

Related questions