97th Monthly Technical Session
This month we learn about Single Sign On, building a photo backup system, and how to navigate accessible UIs at HENNGE’s 97th Monthly Technical Session.
HENNGE’s Monthly Technical Session (or MTS for short) is a hybrid remote and onsite seminar usually featuring technical and non-technical topics ranging from no-knowledge-required to reasonably complex.
Beppu Trip Summary
HENNGE’s Cloud Product Development Division and Business Development Division traveled to Beppu, Oita for a working vacation (or workation) for 7 days.
Naoko Gunji, who was the key organizer for the workation, surveyed participating members. She summarises the results:
- The majority of participants responded with a positive review of the trip and would like to attend another one.
- Every participant had met at least one company member they had never met before
- Every participant had the opportunity to talk to new members with whom they had never spoken to before
Overall, the workation was a fun opportunity for HENNGE members to work in an interesting, new environment and improve collaboration and communication between members!
Single Sign-On, Endless Possibilities: An abridged HENNGE Talk
Jon Gaul — a backend Engineer at HENNGE currently working on Access Control — energetically breaks down Single Sign On (SSO) and when to use it over the classical password manager.
Inconvenient security practices result in less secure environments, Jon says:
“At some level, security has to account for human nature. If security is inconvenient, people will make themselves less secure.”
He recommends that developers getting started with SSO should implement social logins — a familiar technology. Social logins leverage well-developed infrastructures from big tech companies such as Google and Facebook that have already invested in security research.
Social login services provide tools for user setup, password storage, password reset, two-factor authentication, and consent management — these are necessary for product security.
Jon further goes on to introduce two standards used in authentication technology: SAML (Security Assertion Markup Language) — an XML-based standard, and OIDC (OpenID Connect) — a JSON standard.
Authentication usually involves communication between various parties:
- The service provider (SP — also known as the “relying party” or client) provides a resource the user wants to access.
- The identity provider (IDP — also known as the authorization server or resource server) provides an ID token (or access token) to authenticate the user or an authorization code (or grant).
- The user (or resource owner) requests access to a resource from the service provider using an ID token (or access token) provided by the IDP.
Jon demonstrates that many companies, such as Udemy, allow custom SSOs with identity providers which support SAML 2.0. He suggests that if you are working on an SSO product — you should market it as supporting SAML.
He further explains that SAML is a time-tested standard that makes it easy to configure tenant rules and use existing employee directories.
Business-to-business developers should support SAML because it relies on features that should already be implemented by any B2B anyway:
- Different user levels
- Per-tenant configs
- Access management
- Custom log-in URLs
Jon concludes:
“SSO is about safety and convenience for individual users and businesses alike”
Building a photo backup system on a single-board computer (SBC)
Recently data ownership has become a concern for many people. Some of our most private and dear data is in the form of photography. Henry Lie describes how he builds a personal photo backup system using a single-board computer (SBC), a hard drive, and a good few hours of debugging.
Henry provides some criteria for his project:
- It should automatically upload photos from the device
- It should operate using a set of reasonable rules, e.g. only uploading on wifi or when the device is charging
- It should provide full data ownership
He notes that Network-Attached Storage (NAS) devices are typically used but are often more expensive, not as powerful, and use proprietary operating systems.
Henry opts to use a Rock PI 4B+ available for around 14000 yen which provides six cores and 4GB of RAM and lower power consumption for a fraction of the price of a Celeron-powered NAS.
The device is managed using Nextcloud, a FOSS self-hosted service which is available as a docker container and provides a convenient mobile application for backup and browsing.
Henry uses an external WD Elements Desktop hard drive to provide storage to the device. He notes that these devices are often very similar to those used for NAS storage (Storage grade devices) and are relatively cheap for large storage (capable of several terabytes).
Guidelines for flashing the OS to the internal memory of the Rock PI can be found on the official wiki.
Once the device is flashed, Henry explains the initial setup:
- Login with the default user
- Connect to the wifi using nmcli
- Create a new user with root privileges and delete the default one
- Update the apt
- Install the missing locales
Once the setup is complete, the device can run headlessly and be accessed with SSH.
Henry formats the hard drive using the ext4 filesystem. The drive is set to automount on startup.
Henry recommends using the convenient script provided by Docker. The containers are configured in a docker-compose file and can be run using:
docker compose up -d
Finally, Nextcloud can be accessed on port 8080 of the local address. A password needs to be generated to use the mobile application. Auto backup can be set up on the mobile device.
Henry concludes that he was able to implement a system that provides 100% data ownership, can easily for expanded for redundancy, and run at a very low running cost. However, it has a higher initial cost, is not accessible from the internet, and does not have the same search features as more well-known services.
Accessible UIs for Everyone
Rob Keleher provides insight into writing more accessible UI’s, some of the challenges one can expect along the way, and where to begin.
Rob describes accessibility (often written as “a11y”) as “Making sure everyone can use your product” — ensuring the product is accessible to and equally accessible by all people.
There are various difficulties people may have when using your product: visual, hearing, cognitive, or motor skill impairments or the inability to use a mouse/ keyboard. He says: “Accessible products need to work for everyone.”
Rob highlights that around 9.6 million people in Japan live with disabilities. Roughly 36.5 million people are 65 or older and are more likely to have an impairment or disability.
Accessibility needs special attention. Product creators may not consider them during normal development processes. A more accessible product has greater reach, and better User Experience (UX) and may even be required by law.
Rob recommends thinking proactively about accessibility to mitigate additional resource costs or inaccessibility fines. The responsibility of producing accessible UI is shared between the designer and developer.
The web provides various tools to preserve a streamlined UI whilst adhering to accessibility standards, such as ARIA attributes or off-screen CSS positions.
Rob mentions three accessibility standards that define how we measure accessibility:
- The international Web Content Accessibility Guidelines (WCAG)
- Americans with Disabilities Act (ADA)
- Japanese Industrial Standard (JIS) X8341–3
Additional, in Japan, the “Elimination of Discrimination against Persons with Disabilities Act” is a law that states that an attempt should be made to provide an accessible product and failure to report accessibility practices to authorities can result in fines of up to Y200 000.
Rob breaks down the 4 principles which make up the WCAG:
- Percievability
- Operability
- Understandability
- Robustness
He also introduces the “Web Accessibility Initiative — Accessible Rich Internet Applications” or WAI-ARIA which expands the HTML specification for accessibility without impacting the UI visually. There are two main features: ARIA Roles and ARIA Attributes.
Finally, Rob provides some preparation hints for producing an accessible UI:
- Don’t over-rely on CSS and Javascript at the expense of HTML
- Use the right element for the right job
- Use the latest web standards appropriately
- Develop test in code to check for proper accessibility
For designers and developers he recommends:
- Try assistive technologies (e.g. screen readers) to understand how they work
- Try turning off CSS or Animations to see if the UX is diminished
- Use accessibility tester tools
Conclusion
Overall, MTS #97 was filled with chunks of fairly accessible insights for non-technical and technical viewers alike. As usual, the event was concluded with a tasty array of foods including sushi, Chinese cuisine, Malaysian cuisine, Indonesian cuisine, and alcoholic and non-alcoholic beverages.
For more information about Single Sign On, a lengthened version of Jon’s talk will be available from Hennge Talks. More content on Accessibility will be available soon from Rob too!
More information about the workation can be found here: https://hennge.com/global/lifeathennge/article/20220725-beppu-gl.html
