SSO attributes on Connect

Here at JobTeaser, in order to enhance and streamline the experience of the platform for the user, we have developed a new SSO system called Connect.

This SSO system can be employed through the following three major SSO protocols:

  • CAS
  • SAML [including Shibboleth]
  • OAuth2.0

To set up an SSO configuration, different information is required according to:

1) the protocol chosen 

2) the specific situation of the institution making the request.

 

However, a piece of information that is always required by JobTeaser to set up a proper functioning SSO configuration is the SSO parameters (also known as claims). These are the pieces of information that the academic institution will release to JobTeaser, in the form of an SSO payload, whenever a user performs a successful login.

We can thus divide these SSO parameters in two types:

Please, bear in mind that this information is released by the academic institution to JobTeaser through the SSO system. This information is not created, managed nor owned by JobTeaser for it comes directly from the database and/or intranet of the partner Academic Institution.

Mandatory attributes

We defined as mandatory the main four SSO attributes without which an SSO cannot properly function. The Academic Institution must release these SSO parameters, otherwise the SSO will not work. They are as follows:

  • First name

    This is the first name of the user.

  • Last name

    This is the last name of the user.

  • UID

    The UID is the unique identifier of the user. It must be persistent in time and unique for each user.

  • Email address

    This is the email address of the user.

    The email address is used on first login by the SSO system to check if a user with the same email address already exists within the Career Center. If the check comes back negative (i.e. no match) then the system will proceed in the creation of the SSO account. If the check comes back positive, then the system will link the existing Career Center account with the incoming SSO profile.

    On subsequent logins, the system will first check the UID and, if no match is found, it will then check again for the email address as a fail-safe measure. If even this final check is failed, then the system will assume that the user is a new user and will prompt them to create a new account.

Additional attributes

Any other SSO parameter that is not part of the aforementioned four mandatory claims is defined as an additional attribute. These attributes are not necessary for the SSO configuration to work properly, however they add corollary information and/or features that can further enhance the capabilities of the SSO in use.

Whether or not an institution is able to release to the Connect system any of the following attributes is entirely dependent on the Institution’s own intranet.

For this reason, it is paramount that you check with your IT team before considering the idea to introduce additional attributes to your current Connect SSO configuration.

Currently, the Connect system supports the following additional attributes:

  • Graduation Year
  • Campus
  • Alumni
  • Authorisation
  • Internship
  • Staff User
  • User Type
  • Programme

Graduation Year

This attribute must be a number and it is used to set the Graduation Year of the user upon SSO connection. Should the user manually edit their Graduation Year on the Career Center, on their subsequent SSO login the system will detect the discrepancy and will amend the information present in the Career Center.

Campus

This attribute must be a single string (as students can only have one campus within the Career Center) and it is used to set the Campus of the user upon SSO connection. If the user manually edits their Campus, on their subsequent SSO login the system will detect the discrepancy and will amend the information present in the Career Center.

Of course, the Campus value sent through the SSO must match one of the Campuses present in your Career Center.

Alumni

This parameter is used to flag an incoming SSO user as an alumni. It requires a boolean value (i.e a value that can be either true/1 or false/0) to work. When the value is true, then the incoming user is flagged as an alumni, whereas when the value is false no alumni status is applied.

By default, alumni status is applied through your Career Center programmes. If you use the alumni SSO attribute, the programmes will no longer apply the alumni flag, as it will be managed through the SSO instead.

Authorisation

This parameter is used to add an additional authentication filter that comes into play after the user has performed a successful SSO login. A straightforward boolean value (i.e a value that can be either true/1 or false/0) is used to flag the incoming SSO users as either authorised to access the Career Center or unauthorised to access it. Here is the message unauthorised students will see:

Untitled.png

Internship

This is a boolean parameter (i.e., its value can be either true/1 or false/0) that determines whether specific students are permitted to apply for internship job ads (i.e., job ads with the contract type set to Internship). If the flag is set to false, the student will be able to view internship job ads; however, if they attempt to apply, an error message will inform them that they are not authorised to apply for that job ad:

Staff User

This is a boolean parameter (i.e., whose value can be either true/1 or false/0) used to identify non-Career Center Admin users as members of your staff. When this flag is applied, the user in question will not be able to apply to job ads; they will, however, be able to perform any other action, such as registering for events or booking an appointment.

This SSO attribute is intended only for student accounts; it will not work correctly if it is applied to a company, recruiter, or Career Center Admin account.

User Type

The User Type (or Profile Type) parameter is a string attribute which, when applied, entails the provision of the desired account type according to the value sent through the SSO.

The accepted values are the following:

  • If “recruiter" is sent then a recruiter account will be created;
  • if “student" is sent then a student account will be created;
  • if an array of [”student", “recruiter"] is sent then a student-recruiter hybrid account will be created;
  • if “school" is sent then a Career Center Admin account of the Administrator type will be created
    • there is no need to send a combination of [”school", “student"] since all Career Center Admin accounts will always have a student profile associated with them (used to browse the Front Office);

Any other value, or any other combination of values, that is sent through the SSO will not work and might not trigger the correct account type creation (e.g. sending "company" will have no effect).

Programme

The programme additional parameter can be used to manage the courses of the students through the SSO system. This can help making sure that all students present in the Career Center have the correct programme(s) assigned to their account.

When implemented, should a student edit manually their programmes (in a Career Center where such an action is available), upon a subsequent login the system will be able to see the discrepancy and amend the user’s course(s) to match the value of the programme attribute as communicated by the SSO.

If the programme parameter of the incoming SSO user is either empty or absent, the user will still be able to connect to the Career Center, even though they, of course, will not have a pre-filled programme in their account.

The implementation of this additional parameter is comprised of two steps:

  1. the Linking
  2. the Matching

The Linking corresponds to when the IT Team of the Institution will interface with JobTeaser’s Technical Team in order to set up the programme attribute in the SSO configuration and making sure that the information is correctly received by the Career Center.

The Matching is the next step and it happens within the Career Center itself, in the Courses Module, which means that it can be carried out by any SuperAdmin of the platform.

Each course in the Courses Module is made of three parts:

  1. the Name
  2. the Code
  3. the Course ID

name-code-course.png

  1. The Course Name is the name of the programme and it is what the students and the users within the Career Center will see and interact with. There is the option to provide a translation, if you want, in all the languages that are enabled within the Career Center. When the translation is not provided, the Course Name in the default language of the Career Center is used.

  2. The Programme Code is the unique identifier of each course you create within the Career Center. This means that each course must have a programme code. Normally, it is automatically generated, but you can customise it.

  3. The Course ID(s) are the SSO values corresponding to your Institution’s programmes and courses. These values come directly from your Intranet and have normally no relation to the programmes present in the Courses Module. Each row corresponds to one value meaning that each value does not need to be separated by any punctuation. For example:

Course IDs:

HK-EN 1st row value = HK-EN

ab-fr. 2nd row value = ab-fr. (mind here that the full-stop at the end is part of the value)

archeology-101.es 3rd row value = archeology-101.es

course-ids.png

The Matching works as follows:

1 - You must create, or have created, a course in your Courses Module;

2 - In the Course IDs section of this programme, you must add all the relevant values;

3 - Once you are done you click on save.

And that’s it! The next time one of your students will login through the SSO, if within their SSO information the Course ID(s) present matches any Course ID value within your Courses Module, then the student will automatically be assigned to the corresponding programmes (i.e. the programmes that had the matching Course ID value in their Course ID section).

marie-curie.png

Since this is a Matching game, there are only 2 rules:

  1. There cannot be two courses with the same Programme Code
  2. There cannot be two identical Course IDs within the same programme

This means that you can have:

  • Multiple Course ID values within the same Programme;
    • this means that all SSO user with matching values will have assigned to them the corresponding programme:

multi-c-id.png

  • Multiple Programmes with the same Course ID value (this will work only if you authorise users to have multiple programmes in your Career Center);
    • this means that an SSO user with that Course ID will have automatically assigned to them all the programmes in the Courses Module that have a matching values in their Course ID(s):

multi-programme.png

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.