Every day people, IT systems and increasingly products connect to web applications hosted on a server or in the cloud. Conventional login and single sign-on procedures are no longer sufficient.
Passwords alone are too insecure. Security policies require group-wide authentication methods, compliance requirements a better documentation of user identification and their actions. And the new EU data protection regulation DSGVO demands the restrictive handling of personal data.
In addition, system users become more mobile and change end devices and work locations. Virtual organizations and short-term collaboration make it increasingly difficult for companies to determine who (or what) is authorized to use an application at a certain point in time.
These topics are driving the development of new, improved authentication methods.
Identity verification as a central service
"Who are you and what are you allowed to do" is the question to be clarified during the registration process. The identity of persons, software agents or IoT devices is linked to an authorization that is derived on the system side from roles, groups, rights profiles and the like. The more important the authorization the stricter the rules for the secure determination of identity: for example, in the case of a person who can initiate a production release.
Today, identity management is often outsourced to external providers. Many apps focus on application logic and leave user management to others. In the B2C sector, these are mainly Facebook, Google & Co. Solutions such as AccessManager from NetIQ (formerly Novell), Microsoft Active Directory or cloud systems such as MS Azure and others dominate the B2B sector.
This Identity-as-a-Service (IDaaS) concept offers companies with complex IT landscapes many advantages. Compliance requirements, such as a multi-factor authentication with smart cards, can be implemented centrally instead of for each application. User data and, depending on the level of integration, their authorizations in the individual systems are managed in one place. An IaaS provider deals with security issues such as encryption or patch management in a focused manner and with the necessary competence, often even with the corresponding certifications.
OpenID Connect
Single Sign-On (SSO) and central user administration via LDAP directory services are nothing new for companies. However, the older processes have serious disadvantages in the complex and dynamic environment of hybrid clouds and mobile devices.
OpenID Connect, on the other hand, takes into account the need for fine-grained access methods and privacy-by-design, as required by the DSGVO, for example. It is, also in terms of its user interface, tailored for use with web browser-based systems. The protocol builds upon the proven OAuth2 authorization concept and supplements it with the necessary components for authentication.
Unlike older methods, the user communicates directly with the identity provider. This has several advantages: An application cannot lose access data because it cannot see them. No additional training is required, since users log on to the company portal or another identity provider as usual. A portal can also offer SSO as long as the last authentication of the user is still valid and he is not explicitly requested to log on again.
Implementation in CONTACT Elements
CONTACT Software offers companies with its technology platform Elements three options for the use of OpenID Connect.
Client application
Companies use a client that integrates into an OpenID Connect infrastructure and obtains authentication services from an external identity provider. For example, if a user logs on to a Microsoft Azure Cloud, he or she can also get access to CIM Database PLM or Project Office.
This model largely corresponds to the classic Kerberos and LDAP-based logon procedure, only with the new possibilities of OpenID Connect in a process adapted for cloud and web-based services.
Identity provider
CONTACT Elements itself becomes an identity provider for all solutions that are capable of OpenID Connect. An on-premise running web application such as GitLab then uses this central service for authentication, but not for other functions.
This option is especially interesting for smaller installations where CONTACT Elements already contains user data, passwords and permissions. Companies can delegate the logon to other in-house applications to our platform and save the effort of setting up their own OpenID Connect provider.
Authorization system
The third option of our implementation of OpenID Connect concerns "machine-to-machine communication". This allows a user to grant external applications access to the REST interfaces in CONTACT Elements. In this way, other systems or services are integrated via web browser to perform certain actions in our software solutions on behalf of the user. Just two examples from a multitude of possible scenarios:
- Completing a code change in GitLab automatically triggers a status change for an associated task in CIM Database PLM.
- A specialized tool analyzes the newly created documents of a project manager, automatically creates a summary and stores it in the central database without the user having to be online.
All those who want to know more about the possibilities and functionality of OpenID Connect will find some helpful links below. Customers and partners also have the option of interacting with our security experts.
