Authentication 11.0.0

1. Design

1.1 Page Title and Content

The page title and content, including inline elements, appear as per the Default template.

1.2 Related Assets

Articles using the Authentication template display related images, media items, forms, polls and features as per the Default template.

Articles related to an article using the Authentication template are output as a series of links beneath the other page content. These links are designed to take users to the site's registration article and could also be used to link to a "forgot password" form and process, if one has been implemented for the site. These links are output with an authlinks class, so can be styled as buttons using your site's CSS.

1.3 Login Form

The login form is generated by the Authentication worker. You can read about it in the 10.0.6.0 Authentication worker documentation.

The actual login options displayed on the form can be controlled using the article extras of the Authentication template.

1.4 When Will Users Log In?

There are two scenarios that will prompt a user to log in.

1.4.1 Authentication Challenge

If a non-authenticated user tries to access secure content, they have to log in. The user will be directed to the site's login article, which uses the Authentication template, and once they've authenticated, they'll be redirected back to the secure content they were trying to access.

Upon reaching that secured content the user will either be able to view the content, or be presented with a "Security Denied" message (set in the subsite configuration) should the content be secured to a security group the user is not a member of.

1.4.2 Direct Login

A non-authenticated user may also log into the site by navigating directly to the site's login article. After successfully authenticating the user will be directed to the "Welcome" article in the article extras. If an article has not been set, the user will be directed to the site's homepage.

1.5 Failed Logins

Should a user fail to authenticate when logging in using the "already a member" method, they will be presented with an error message advising them that either the username or password entered was incorrect. Multiple attempts to log in with a valid username but incorrect password will cause the user to become locked out. Both the lockout threshold and lockout duration are configured in the Authentication worker.

2. Configuration

The Authentication template is one part of the GOSS Authentication Product. The full product also includes the API Server's Authentication worker, iCM's Site Groups and Users, optional connections to external authentication providers, and iCM Forms which handle user registration, password management and user profile information.

2.1 Configuring the Site Login

An article using the Authentication template can be configured via its article extras as follows:

1. Log out text. When a user is logged in, the log out text will be used when outputting links to the login article instead of the article heading or alternate link text. If left blank, the value "Log out" is used. When this link is clicked users will be automatically logged out of the site. They will remain logged into any external authentication providers if they logged in via a third party (ie if a user authenticates using Facebook, then logs out of the iCM powered site, they will remain logged into Facebook). This behaviour is outside of our control.
2. Welcome article. If the user was prompted to log in when trying to access a secure article or content (the target content), they will be redirected to it on successful login. If no such target content can be identified, the user will instead be redirected to the selected "Welcome" article. If a welcome article is not selected, the user will be redirected to the site homepage.
3. Default groups. A list of the groups that a user authenticating with the site will be added to. If you change these groups, the next time a user logs in, they'll be added to any additional groups. User's aren't ever removed from groups (otherwise your staff members would be removed from their secure groups when logging in)
4. Enabled authentication providers. The authentication providers a user is able to sign in with. These providers must first be configured in the API Server's Authentication worker. Only providers that have been configured will appear here. Checking a box will cause that provider to appear on the login article.
5. Enable LDAP authentication. Check to allow LDAP Authentication. For LDAP/Windows authentication to function the server will need to be appropriately configured.

2.2 Site User Creation

After successfully authenticating against an external provider, user details are retrieved, mapped to the Authentication worker's UserProfile class, and a site user created or updated. A user's profile data is updated each time they log in via that provider.

iCM Site Users are created with a name built from the configured provider's userPrefix parameter plus a unique identifier returned from the third party provider, eg "FB_" + "1234567890".

Site users are added to the groups set in the article extras of the login article. This should normally include the "default" security group for your site. Users will also be added to a group named after the type of external provider that created them, using the providerName set in the configuration of that provider. Should this group not already exist it will be automatically created.

2.2.1 Example Site User

The following user was created after authenticating via Facebook.

The user has been made a member of four groups.

The first of these is the default Facebook group automatically created by the Authentication worker, the remaining three were assigned at the time of login, and are set in the article extras of the Authentication template article.

User identities created after authenticating with an external provider cannot be used by a user to log in via the iCM Site User username and password method (the "already a member" option), despite them existing as site users in iCM. The username of the identity created will never be known to the user and the password is not stored in iCM. Authentication is handled entirely by the external provider.

3. Article Extras