Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Google Integration

  1. Why does Coworking Access Control Sync require all of these permissions from Google?

    • <INSERT screenshot of Google permission screen here>
    • Calendar - CACS does not talk directly to Liquidspace.  Instead, it watches a Google Calendar (that you have LiquidSpace sync to) for booked reservations.
    • Manage my email - In order to sidestep spam problems, when CACS emails the person that booked reservation with their badge info, it is desirable to use your facility's email address as the 'from address.'  This increases the likelihood that the user will recognize the email.  In order to do that, CACS must authenticate to Google's SMTP servers.  Google provides a way for CACS to send email on your behalf without giving CACS your Google password.  The problem is, Google does not currently differentiate between giving CACS access to send email on your behalf and the permission to read your email.  See this link @ Google for more information.  Unfortunately, what this means is that for the moment, you just have to trust that we're not reading your email.  That is far from ideal and you shouldn't have to do that.  As soon as Google splits IMAP and SMTP OAuth scopes, we can change this.  In the meantime, we decided the tradeoff is worthwhile.

  2. How do I view what emails have been sent by CACS?

    • Emails sent to users will be visible in the 'sent mail' of the Google account you configure in the tool, just like ordinary emails.

System Requirements

  1. Why is a Windows PC required?

    • There is nothing inherent to CACS that needs Windows or .NET.  We chose .NET and Windows mainly because coworking facilities with Isonas Access Control already have a Windows PC there running the Crystal Matrix software.  Rather than add to the list of software platforms someone needs to keep up to date, we went with windows.

Isonas Integration

  1. Why do you require AES encryption?

    • Without this, it would be very easy to read your Isonas password, badge codes, and other customer information while in transit between CACS and Isonas's INRServ process.  We take advantage of Isonas's AES setting and use a Windows facility to manage the encryption key in order to reduce the chance of Isonas credentials/badges getting exposed.

Security

  1. Do you store my Google credentials?

    • CACS never sees your Google password.  We only see OAUTH tokens that grant us access to specific Google services (email, calendar data) that you participate in.

  2. How is my Isonas password and encryption key stored?

    • We work with the password and encryption key as .NET SecureString objects in memory.

    • When we store the SecureString objects, we encrypt the contents using a PInvoked DPAPI call and then store the encrypted, base 64 encoded string in a .NET settings file.

  3. Can BSW Technology Consulting access my Isonas system?

    • No.  There is not currently any BSW service outside the firewall that can connect to your system.  Limited logging data for diagnostic purposes is sent to BSW Technology Consulting.
  • No labels