Cyberaware supports Single Sign On (SSO), a process that allows users to authenticate themselves against an external Identity Provider (IdP) rather than obtaining and using a separate username and password handled by Cyberaware.
Under the SSO setup, Cyberaware can work as a Service Provider (SP) through SAML (Secure Assertion Markup Language) allowing you to provide Single Sign On (SSO) services for your domain.
What you will need, is a ADFS 2.0 Identity Provider (IdP) which will handle the sign-in process and will eventually provide the authentication credentials of your users to Cyberaware . Cyberaware users authenticated through your ADFS 2.0 IdP are handled from your IdP and any change they perform on their account (namely first name, last name, and email) are synced back to their Cyberaware account. The only user data that is necessary for Cyberaware is a unique identifier for each user, user's first name, last name and email. Cyberaware does not store passwords.
Step 1. ADFS 2.0 Configuration
Consider that for the current procedure, your ADFS 2.0 server is hosted in win-0sgkfmnb1t8.adatum.com. (Do not forget to replace win-0sgkfmnb1t8.adatum.com with your ADFS 2.0 server actual domain name when following this procedure).
Open the ADFS 2.0 Management through Start→Administrative Tools→ADFS 2.0 Management.
Right-click on Service from the left tree-view and click on Edit Federation Service Properties.
In the General Tab you can find the Federation Service Identifier, which is the Identity provider URL. You’ll need to fill this up in the Cyberaware Single-Sign-On (SSO) configuration page. For the current procedure the Identity provider URL is http://win-0sgkfmnb1t8.adatum.com/adfs/services/trust. Check the rest values in General Tab and confirm that they match your DNS settings for your server.
Click on the Certificates Entry from the left tree-view, right-click on Token-Signing certificate and then click on View Certificate
In the Details Tab click on Copy to File and the Certificate Export Wizard launches. Click on Next, select DER encoded binary X.509 (.cer) format, and then click Next. Choose where you want to save the certificate and click on Finish.
Cyberaware requires a PEM format certificate. So you will need to convert the certificate to PEM format using any appropriate tool or even online tools such as www.sslshopper.com(https://www.sslshopper.com/ssl-converter.html). Convert the certificate from DER to PEM format. You will need it during Cyberaware configuration in Step 4. Keep in mind that Cyberaware will work with RSA certificates. DSA certificates are not supported.
Step 2. ADFS 2.0 Relying Party Trust Configuration
At this step you are going to define the Cyberaware endpoints in your ADFS. You can do this manually or you can import the metadata XML provided by Cyberaware. You are advised to do the latter, since it is more easier to implement.
Given that your SSO enabled Cyberaware domain is company.cyberaware.com you can find The Metadata XML file at the following address (you should replace company.cyberaware.com with your actual Cyberawaredomain):
Go to this address and download the XML file.
In the case where you find it difficult to access this URL, the Metadata XML looks like the following (again do not forget to replace company.cyberaware.com with your actual Cyberaware domain:
<?xml version="1.0"?> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="company.cyberaware.com"> <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol"> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://company.cyberaware.com/simplesaml/module.php/saml/sp/saml2-logout.php/company.cyberaware.com"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://company.cyberaware.com/simplesaml/module.php/saml/sp/saml2-logout.php/company.cyberaware.com"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://company.cyberaware.com/simplesaml/module.php/saml/sp/saml2-acs.php/company.cyberaware.com" index="0"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://company.cyberaware.com/simplesaml/module.php/saml/sp/saml1-acs.php/company.cyberaware.com" index="1"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://company.cyberaware.com/simplesaml/module.php/saml/sp/saml2-acs.php/company.cyberaware.com" index="2"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://company.cyberaware.com/simplesaml/module.php/saml/sp/saml1-acs.php/company.cyberaware.com/artifact" index="3"/> </md:SPSSODescriptor> </md:EntityDescriptor>
Select Relying Party Trusts from the left tree-view under the Trust Relationships,right-click on the Relying Party Trusts and click on Add Relaying party Trust. The wizard launches.
Click on Start and Choose Import data about the relying party from a file.Click on Browse and locate the Metadata XML file of your Cyberaware domain.
Click on Next, ignore the pop-up message and type a distinctive Display Name (eg. Cyberaware) and click Next.
Select Permit all users to access the relying party and click Next to Finish.
On the center Column right-click on the relying part you’ve just created (eg Cyberaware) and the select Properties.
On the Advanced Tab select SHA-1 for the Secure hash algorithm and click on OK
Step 3. ADFS 2.0 Claim Rules Configuration
In order to configure a proper communication between your ADFS and Cyberaware, you should define the Claim Rules
On the center Column right-click on the relying part you’ve just created (eg Cyberaware) and then select Edit Claim Rules.
On the Issuance Transform Rules Tab click on Add Rules. The wizard launches.
Select Send LDAP Attribute as Claims and click on Next
Define the Claim rule name (eg. Get LDAP Attributes) and select Active Directory in Attribute Store. In the Mapping of LDAP attributes to outgoing claim type select the following:
LDAP Attribute: E-Mail-Addresses, Outgoing Claim Type: E-mail Address
LDAP Attribute: Given-Name, Outgoing Claim Type: Given Name
LDAP Attribute: Surname, Outgoing Claim Type: Surname
LDAP Attribute: User-Principal-Name, Outgoing Claim Type: UPN
and then click on Finish
Add a second Rule following the same procedure. Select Transform an Incoming Claim and click on Next.
Define the Claim rule name (eg. Email to Name ID) and set Incoming claim Type as E-Mail Address (the same one from the previous rule), Outgoing claim type as Name ID and Outgoing name ID format as Email.Then click on Finish. Have in mind that the email should be defined in all users to achieve a proper communication between your ADFS and Cyberaware.
Step 4. Configure authentication policies
In order to ensure that single logout (SLO) works properly, especially in the case where multiple users login from the same machine, you need to configure authentication settings for the relying party trust you've just created.
Expand Authentication Policies from the left tree view, and click on the Per Relying Party Trust option. Then in the center Column, right-click on the Cyberaware relying party trust, and select Edit custom Primary Authentication. At the Primary tab, check the option Users are required to provide credentials each time at sign in and then click on Ok.
Step 5. Enabling SAML SSO in your Cyberaware domain
Login to your Cyberaware domain as a super-admin and go to Account & Settings → Users. If your subscription plan supports SSO Integrations (currently supported in Basic, Plus and Premium plans), you can click on Single Sign-On (SSO) link.
In this page you should fill-in information regarding your Identity Provider (ADFS 2.0). All the required information can be retrieved from the IdP’s Metadata XML that can be found in the following URL:
Do not forget to replace win-0sgkfmnb1t8.adatum.com with the domain name of your ADFS 2.0
SSO integration type: Choose SAML2.0 from the drop-down list
Identity provider (IdP): type the Identity Provider's (IdP) URL
Certificate fingerprint: Locate the certificate in PEM format extracted in Step 1, open it with your favorite plain-text editor and copy its contents. Then paste them in the text area that will appear when you click on the “paste your SAML certificate (PEM format)” link. The SHA-1 Certificate fingerprint will be computed when you click on the Save button. Keep in mind that Cyberaware will work with RSA certificates. DSA certificates are not supported.
Note: Cyberaware works with RSA certificates. DSA certificates are not supported.
Remote sign-in URL: fill-in the remote sign-in URL of your IdP. This is the URL where Cyberaware will redirect your users for signing-in.
Remote sign-out URL: fill-in the remote sign-out URL of your IdP. This is the URL that Cyberaware will redirect your users when they sign-out.
The rest of the fields are used to define the variable names of the SAML protocol containing user data provided by your IdP, that is essential for Cyberaware. Avoid the use of variable names with underscores ( _ ). For example do not configure your IdP to send First Name with the variable "given_name". Instead prefer to use "givenname".
TargetedID: this is the username of the user account and should be a unique identifier for each user. In our case this is the User-Principal-Name defined in Claim Rules in Step 3.
First name: the first name of the user.
Last Name: the last name of the user.
Email: the email address of the user.
Note that email is essential for Cyberaware communication, so you should make sure that all users have valid email addresses.
- Group: the group(s) name(s) that the user is member of. This SAML variable may hold a single string value (group name) or an array of string values (groups names). If group with the same name exists in your Cyberaware domain, then the user will be assigned in that group and will get all courses of that specific group on his/her first login. The option “Add assigned groups with each login” can be selected to force group assignment on each login. Have in mind that with this option the user is not removed from groups to match those send by your IdP. Instead, only assignments to new groups are performed.
EXAMPLE ADFS PARAMETERS TO PROVIDE TO US:
Identity provider (IdP): http://win-0sgkfmnb1t8.adatum.com/adfs/services/trust
Certificate fingerprint -> Paste SAML certificate in PEM format:
Remote sign-in URL: https://win-0sgkfmnb1t8.adatum.com/adfs/ls/ (Make sure the link is https and /adfs/ls is added)
Remote sign-out URL: https://win-0sgkfmnb1t8.adatum.com/adfs/ls/?wa=wsignout1.0 (Make sure the link is https and /adfs/ls/?wa=wsignout1.0 is added)
TargetedID : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
First name : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
Last name : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
User Account Matching
At the time of writing of this document Cyberaware provides a passive mechanism for User Account Matching. This means that existing Cyberaware user accounts are matched against SSO user accounts based on their username.
User account matching is only possible in the case where the username provided from your IdP is exactly the same with the an existing Cyberaware account's username. In this case the Cyberaware user account state will remain unchanged during SSO login process. However first name, last name, and email will be pulled from your IdP and will replace existing values.
If the username provided by your IdP, for an existing Cyberaware user, is different from his/her Cyberaware username, a new account will be created with the IdP provided username. In this case there will exist two different accounts for the same person.
To ensure that User Account Matching will be performed successfully, you should configure your IdP to sent the same username for existing user accounts. The SAML 2.0 attribute name that carries the username can be defined in the TargetedID field at the Cyberaware SSO configuration page.
Even though your users are allowed to change their profile (first name, last name, email and username) this is strongly discouraged. Changing first name, last name and email will impact only the current session. The next time a user signs-in, those values will be pulled from your IdP server. Changing the username, will result on the undesirable effect of user mismatching, since users are matched based on this value. So, you should notify your users how SSO affects your Cyberaware domain and avoid changing first name, last name, email and especially username form their profile.
If your users are authenticated only through SSO it is a good practice to disable profile updates for your users by changing the specific user group permissions. To disable profile updates for your learners go to dashboard click on User Types →Learner-Type→ Generic → Profile and make sure that "Update" and "Change password" are not checked.
You have now configured your Cyberaware domain to provide SSO services. Your users may login to your Cyberaware domain using the username and password stored in your ADFS 2.0 Identity Provider.