Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Sakai 22 Browser Support

...

If your not sure which to use here are some honorable mentions: nginx, Apache httpd, HAProxy

Database

...

Here is a list of of supported databases

  • MySQL 5.6

...

  • or 5.7
  • MariaDB 10

...

  • +

...

  • Oracle 12c+

The most popular choice , Oracle 12c.  Database support detailsis MySQL and is the recommended.

Clustering, file storage and load balancing strategies

A typical Sakai cluster is comprised of one or more application servers running one or more instances of Tomcat 9 operating either in standalone mode or behind the Apache HTTPD load balancera proxy that can load balance. Each Tomcat instance runs a full copy of Sakai. The cluster is backed by a single database providing a transactional store of information.

Storing binary content outside the database is a configurable option in Sakai and highly recommended from a performance standpoint. Most Sakai schools with sizable user populations opt for network-attached storage (NAS) or storage area network (SAN) solutions. External Authentication choices

Authentication

Sakai has it's own local authentication or you can configure it to use external authentication to achieve single sign on.

Sakai can integrate with a variety of external authentication services including CAS, Kerberos, LDAP, ADFS, and Shibboleth.some of which are:

  • CAS
  • Kerberos
  • LDAP
  • ADFS
  • Shibboleth

Integrating with student information systems

...

Sakai has two basic approaches to integrating data from external systems. Most sites use a combination of these approaches. The first approach is to use the internal Sakai "provider" APIs. These APIs are places for Sakai to "consult" while Sakai is running. There are APIs for User Identity, User Directory, Course Listing, and User Roles.

  • User Identity API

...

  •  allows Sakai to call local code to validate users

...

  • during authentication
  • User Directory API

...

  •  allows user information such as name and e-Mail address to be retrieved from an external system such as LDAP or X.509. The User Directory API has provisions to allow the local site to make decisions when to display student information in order to meet FERPA requirements

...

  • Course Listing API

...

  •  consulted when the instructor is creating a course site - this API returns the list of externally stored rosters for which the current user is the instructor. The user can select from one or more of these external rosters to associate with the course they are creating

...

  • User Role API

...

  •  is consulted

...

  • during authentication to determine which external rosters

...

  • the user is a member of and what their role is within those rosters

...

The above API's are "pull" APIs--they are consulted when the user logs in or tries to take some action. The Course List API described above does not auto-populate courses.

...

A more common approach to pushing data (e.g. enrollment and course information) into Sakai is through web services. Many of Sakai's APIs can be accessed by web services. Web service access points have been developed for many of the common Sakai APIs used for configuration. These REST and SOAP web services can be called from PHP, Python, Perl, Java, . NET or any other language. The Sakai web service data structures are kept simple to insure the widest possible interoperability with as many languages as possible. Administrators often build scripts to pull data from their SIS system and populate Sakai with that data. These scripts may be automated using cron or manually executed by the administrator at the proper time during a semester.

This combination of pull/push configuration capabilities allows for a very wide range of integration possibilities for Sakai.