| title | Not done writing |
|---|
Hearing Health Care Industry Common Identity Services
<Brief description of what it is. Consider using an analogy to using your Linkedin Account.
- Single sign on for web based applications but more
- <not
<Will authenticate that an individual logging in as fjones@email.com is the authorized user of fjones@email.com. This user will be challenged to authenticate this by means such as:
- entering in a correct password
- using a MFA device/system (app, hardware)
- can be updated overtime to move with the changing times
The identity service will not go further to in other ways validate that Frank Jones using fjones@email.com is really Frank Jones
A HCB makes use of another Identity Service such as MS Active Directory or Azure Active Directory that meats the needs of a large enterprise setup, HIMSA's identity service will be able to integrate with that other system.
<Using IT industry standards and best practices for the implementation
Directory Features
The identity service will also provide for the storage of basic information about the HCB, its offices (address and location name) as well as basic information about the employees that make use of the Identity service
How HIMSA will use the Identity Service
Service Apps are applications that can come in many forms, web sites/portals, order applications etc. Noah ES is also a service app, an application that provide data hosting and other related services. When HCB's sign up for Noah ES they are also seamlessly creating and identity account as well. When logging into Noah ES the user will be authenticated by the HIMSA identity service
<AS the ID world gets more complicated the IdP can be made to meet these challenges while not impacting the members, the user benefits are also nice, this alllows the members to implement different systems by making it easier the user to have a smoother experience.>
How HIMSA Members may use the Identity Service
<could be used as a replacement to their current login systems or as an option>
<really need a simple example - logs into Noah ES, security token is established on the device (PC) from Noah or from outside of noah goes to web site and the service obtains security token and gets the user into acvity witout stopping to provide authorizaiton
<Make a point that their app is still completely in charge of authorizing what HCP's are able to do in their application>
Audience
This introduction has been created for HIMSA Member Companies and Employees. Some content is useful for Hearing Care Businesses (HCB) and Hearing Care Professionals (HCP), but different publications will later be prepared for these groups.
The content is prepared assuming it will be read by product/project managers, software developers, or IT specialists.
Introduction
With Noah ES, HIMSA has implemented a service that uses IT industry standards and best practices to ensure that the Hearing Care Professional (HCP) is, for example, Brian Jones, who uses the email address bjones@email.com. Once authenticated, Brian can make use of the Noah ES features. At this point, Brian's HIMSA Identity is available for other approved applications to make use of.
HIMSA SSO and Noah ES accounts were designed to be used by HCBs so that all applicable employees could be managed under one account for the HCB.
Q: Is the business that Brian works for required to subscribe to and use Noah ES to use HIMSA SSO?
A: No. HIMSA has created a new product called HIMSA SSO (Single Sign-on), which is free for Hearing Care Businesses (HCB). Current Noah ES customers already have a HIMSA SSO-based identity.
Identity
The main identity of a HIMSA SSO user is their email address.
| Tip |
|---|
Behind the scenes the true identity is comprised of:
This enables users to:
|
Q: A common question that HIMSA receives from HIMSA member companies is - “Is HIMSA verifying that bjones@email.com is really Brian Jones, a licensed HCP located in the United States?”
A: No, HIMSA SSO is not able to promise this. HIMSA SSO can claim that bjones@email.com is part of a business set up in Noah ES or HIMSA SSO AND has control of the email address bjones@email.com. HIMSA SSO sends a special and limited-use link to the registered email for the user to complete their user account setup.
This topic is continued in the Authorization section.
Who Benefits?
HCBs and HCPs
HCPs stand to gain the most from HIMSA SSO. With this system, they will only need to use one user account (email address), password, and possibly another MFA device when accessing other industry websites and services.
Q: Why not focus on asking HCPs to use other solutions such as Google, Apple, and Microsoft account integration that are often on many websites today?
A: HIMSA SSO is designed to be a business account. This means that it is possible for the business administrator to centrally manage the users that are associated with their business. For example, if Brian Jones resigns from HCB A, it is only necessary for the HCB to deactivate his HIMSA SSO user account. Brian Jones will also not be able to gain access to any member applications with the HIMSA SSO account + email address combination, as authentication will no longer be possible.
HIMSA Member Companies
It is fair to say that supporting HIMSA SSO will create more work for HIMSA member companies. The main focus is to remove pain points (e.g., HCPs do not need to remember user names and passwords for each web service they use. Additionally, centralizing user management for HCBs will be appreciated.)
It is envisioned that removing this pain point will make it easier for member companies to promote their web applications.
Q: Does HIMSA assume that HIMSA SSO will replace current or newly implemented identity and authentication systems a HIMSA member company implemented for their own applications (e.g., often referred to as “local accounts”).
A: No. Additionally, looking at similar systems in other industries, it is normal for the application to provide a “local account” as well.
HIMSA
HIMSA hopes to use HIMSA SSO to draw attention and grow the adoption rate of Noah ES while helping promote the use of cloud-based applications.
Authentication
Authentication of bjones@email.com is currently accomplished via Brian entering his HIMSA SSO password. Once the password is entered correctly, the user is considered authenticated.
HIMSA SSO also provides additional authentication options
Brian’s user account can be set up to require MFA codes texted to a registered phone number
Brian’s company may also subscribe to advanced identity systems (e.g., Azure AD) and still use HIMSA SSO; see the “Advanced Systems” section below
Note: HIMSA makes uses of Microsoft B2C authentication services to support authentication via password and MFA.
Authorization
Authorization is solely provided by the application provided by the HIMSA member company. Noah ES has no features that attempt to standardize authorization.
Authorizing an HCB and/or HCP can be accomplished by:
Use the HIMSA SSO API to determine if the account is a Noah ES or HIMSA SSO account
Use the API to determine if the current interactive user is set up as a Business Decision Maker, Administrator or regular user.
| Tip |
|---|
|
Easy Identification
During the day, Brian may need to use a website application provided by manufacturer A. Manufacturer A is a HIMSA member company and is a trusted integrator with the HIMSA SSO. In this example, Brian is wishing to make use of an order system.
When Brian arrives at the website, he can access protected functionality without using different credentials.
Q: Does this mean that the member companies ' websites automatically use Brian’s credentials?
A: No, Brian will most likely need to enter his HIMSA SSO credentials. This is also impacted by how recently Brain has used the member's website and how long the website has been configured to allow Brian to use it without having to be authenticated again.
Seamless Movement Between Different Systems and Companies
Brian's company also works with Manufacturer B which provides a web-based system for remote fitting/care. Even though the systems are completely separate, Brian does not need a different user account but can rather use his HIMSA SSO Identity to gain access to the remote care functionality.
Q: Since Brian can log into systems provided by manufacturers A and B does this mean that, for example, manufacturer A can gather some data or insight into the activity related to manufacturer B?
A: No, this is not possible.
Directory Features
HIMSA SSO provides for the storage of basic information about the business, such as location name, address, and other contact information.
User types, such as Business Decision Makers (i.e., can sign agreements with HIMSA) and Administrators, are also defined.
Manufacturers Benefit
Location and User Information is available to manufacturer applications to assist in onboarding a business as easily as possible. Manufacturers will also be able to determine when HIMSA SSO accounts have been disabled, signaling that the individual is most likely no longer employed. The manufacturer may take any action within their applications if they wish.
Advanced Systems
Hospitals, large chains/groups, businesses with special security needs, or advanced setups (e.g., use of a physical PIV card) have already had most of their software systems set up to use products such as Microsoft Active Directory or Azure Active Directory.
These businesses really dislike using separate identity systems as each separate system represents a level of complexity for the administration of their business. These businesses will most likely not accept to abandon their chosen solution for HIMSA products as well as other online-based systems.
To accommodate this situation, HIMSA SSO is implemented and ready to integrate with other approved systems so that HIMSA can still deliver a high-quality identity for uses with Noah ES and associated applications.
Manufacturers Benefit
HIMSA SSO supports this type of integration, so manufacturers do not need to worry about it. As far as the manufacturer is concerned, it is just working with the HIMSA SSO Identity Service. For example, if Brian's company has decided to use Azure Active Directory, this change will have no impact on manufacturer-created applications.
Future Proofing
Identity and authentication for software applications is a fast-changing field that will likely change quickly during the next few years. For example, the next large change is assumed to come with moving away from using passwords and replacing them with authentication Apps and easy-to-use hardware devices. Microsoft and other companies are working very hard on addressing this topic. Rather than forcing users to deal with the ever-increasing number of password changes and complexity, other methods are sure to become the standard in the future.
Manufacturers and HIMSA's Benefit
As this field changes, HIMSA SSO will be able to make adjustments to the Identity Management Systems to make use of new standards without causing a direct impact on the development of Noah ES or applications that integrate with Noah ES or the Identity Services.
In other words, HIMSA can perform the work once, and all companies may then enjoy the benefit of this work.