External Authentication
CloudShark allows users to authenticate against the local database or against external network directory information services such as LDAP, Active Directory (AD), Kerberos, or a Single Sign-On SAML 2.0 provider. Google, and Okta can also be used to authenticate users using OAuth.
CloudShark maintains group membership locally or accesses group membership information using the same network directory information services. Local and external users modes may exist simultaneously, allowing a single CloudShark system to include both local and external users.
Methods of External Authentication
If you are using LDAP or Active Directory to provide external authentication visit our LDAP and AD Authentication article to configure CloudShark to authenticate against these servers.
If you are using a SAML 2.0 Single Sign-On server, follow the instructions in the Single Sign-On Authentication article.
If you are using OAuth with Google, or Okta use the instructions in the OAuth Authentication article.
Managing External Users
When external authentication is enabled, CloudShark will create an account for each user the first time they log in. To change this default behavior visit the Authentication page of the Administration menu and uncheck the Create accounts on first-login checkbox. When this is disabled all user accounts must be provisioned first by a CloudShark administrator before the external user is able to login.
When an account is created using external authentication the Default User Settings will be used to create the user. Visit the CloudShark Users page for more information on setting up **Default User Settings. **
Managing External Groups
External groups can be used to restrict access to capture files within CloudShark by creating a local group that maps to one or more external groups. Any external user that is a member of the included external group(s) will then be automatically associated with the new CloudShark local group.
For example, assume there two external groups named cloudshark-admins and cloudshark-users. Assume that these groups have the following members:
- cloudshark-admins: Matt, Tina
- cloudshark-users: Bob, Fred, Frank
The cloudshark-admins group represents the set of users that should have administrative privileges within the CloudShark system. This can be implemented by editing the predefined local group Admin within CloudShark and adding cloudshark-admins to the external groups list. Now any member of the external cloudshark-admins group, initially users Matt and Tina, will be automatically associated with the internal Admin group and be given administrative privileges within CloudShark.
Likewise, the cloudshark-users group represents the set of users that should have basic, non-administrative privileges within the CloudShark system. This can be implemented by creating a new local group, ie Users, and adding cloudshark-users to the external groups list. Now any member of the external cloudshark-users group, initially Bob, Fred, and Frank, will be automatically associated with the internal Users group and be given specific non-administrative privileges as defined by members of the Admin group.
Membership in either group can be managed through the external authentication system via the cloudshark-admins and cloudshark-users groups. In addition, CloudShark admins can manage membership via the local Admin and Users groups.
