Single Sign-on Guidelines

API

There are a number of considerations that need to be taken into account when implementing single sign-on and access controls using a Currinda database as a backend.The most important consideration is that Currinda will authenticate a user that is not a current member. This means that the membership payload should be inspected for a current membership. This is should be checked by the ExpiryDate in the Membership record with the current date. This functionality is by design and should be utilised by the implementor to offer options for a member or potential member who has no membership, or a cancelled or expired membership.The specific logic of what an expired member can see is left for the implementor and the association to decide however, these cases must be handled on the implementing site and links back to the Currinda database should be offered especially in the case of outstanding memberships.The extra statuses that should be implemented are:

  • Incomplete (This is a user that has not completed their registration)
  • Unchecked (This is a member that has not been verified by the association)
  • Expired (This is a member who's membership has lapsed)
  • Outstanding (This is a member who has money outstanding, but possibly a valid membership)
  • Current.

Another important consideration for implementors is Currinda's different membership styles. Currinda has 3 distinct membership styles. - Individual - Corporate

  • Corporate Submember

Each user can have at most 1 individual membership, but may be the contact of many corporate memberships. Each distinct membership will have it's own expiry dates and outstanding status. If the association database implements corporate memberships these must be displayed and be accessible through the implementing site.In the case of a corporate submember, these users are not permitted to make payment or update membership details for the membership and should be treated as such.

Previous
Previous

API v1.0

Next
Next

API V0.1