SSO using client certificates
1. Single Sign-On (SSO) Login
SSO allows a user to have a single password to log in to multiple affiliated web portals and / or web applications. This is very convenient for users, as they do not have to remember many passwords. However, if encryption does not take place here, SSO has a major disadvantage. If a password is leaked or broken, an attacker can access all websites / applications accessible under that password. This disadvantage for most people is a serious reason not to use SSO.
However, there is an authentication method where the portals query the identity of the logged in person to the special authentication portal service. These solutions are known in the Czech Republic as MyID or Bank Identity. Logging in this way is considered safe, because the mentioned service uses cryptography, often indirectly, using a special application like the RB key of Raiffeisen bank.
2. Client certificates
A common use of a client certificate is encrypted communication. It is either the exchange of e-mail messages or the use of the website, web portal, or web applications with https protocol.
To connect the browser to many types of web portals, it is enough to have the root certificate of their certification authority. The connection is then based on the fact that both your browser and the website trust the same certification authority. In addition, the root certificates of many CAs are already preinstalled in browsers.
For client (person) access, it is usually necessary for them to have their client certificate issued and installed. Some security programs on the client computer generate a CSR (Certificate Signing Request) with a public key and a corresponding private key. The user then sends the CSR for signature to the certification authority and receives his certificate. The private key remains in the computer where it was generated and is used to decrypt or encryption (depending on the type of use).
SSL (Secure Sockets Layer, 1.0, 2.0, 3.0) and TLS (Transport Layer Security, 1.0, 1.1, 1.2, 1.3) protocols are used to communicate with mail and web (and other) servers. Due to the vulnerabilities of protocols and their gradual obsolescence, TLS versions 1.2 and 1.3 are now recommended.
3. Combination of SSO and client certificates
The client certificate may be flagged as suitable for SSO login. According to the CAcert document Certificate Practice Statement (CPS, COD6), paragraph 3.1.1, it is a hash of a random number.
The document provided by Oracle further states that SSO requires a Single Sign-On server that receives queries from "federated" partners to which the user-person wants to log in. The SSO server retrieves a copy of the user's certificate from the database and compares it with the request. Therefore, the user certificate must be stored somewhere and the SSO server must have access to it.
Benefits of Certificate-Enabled Single Sign-On
(Oracle, https://docs.oracle.com/cd/A97329_03/manage.902/a96115/pki.htm)
Certificate authentication offers the benefit that partner applications are, by default, PKI enabled when the Single Sign-On Server is PKI enabled. As in Single Sign-On without certificates, these applications rely on cookies for authentication. Retrieving and checking a cookie requires less computing overhead than performing an SSL handshake. For Web applications characterized by short-lived sessions, the result is a significant improvement in server performance and throughput.
Authentication Options
Oracle Single Sign-On can be configured for SSL both with and without client certificates. The first option, server-side authentication, offers a strong degree of security. Still, the user's password is vulnerable to attack--either by guesswork or by brute force. Certificate-based authentication on both client and server sides, on the other hand, makes it difficult to sniff or modify data or to impersonate the client or server.
Authentication Flow in Certificate-Enabled Single Sign-On
Figure 4-1 depicts the authentication flow for certificate-enabled Single Sign-On.
Figure 4-1 Certificate-Enabled Single Sign-On
- The Single Sign-On user tries to access a partner application.
- The partner application redirects the user to the Single Sign-On server for authentication. The server must be configured so that, at the very least, it asks for optional client certification.
- If the server has been configured for SSL, the SSL handshake occurs. The browser prompts the user for a password that opens the browser certificate and key database. The browser then sends the user's certificate to the login URL of the Single Sign-On server.
- Mod_ossl, the SSL module on the Single Sign-On server, passes the user's certificate information to a PL/SQL module that maps the user's nickname and, optionally, his subscriber name.
- The mapping module passes the mapped user name and optional subscriber name to an authentication module.
- The authentication module uses the mapped user name to retrieve the user certificate stored in the directory; then it compares this certificate with the browser certificate received from mod_ossl.
- If the two certificates match, the Single Sign-On server signifies that authentication has been successful by passing a URLC token that contains user information to the application.
- The application redirects the user to the requested URL, which then delivers content.
Single Sign On Certificate Authentication Overview
For security reasons, enterprises may require authentication for their API endpoints and websites, SSO via Certificates allows a developer to leverage enrollment credentials to handle the authentication without prompting the end user of the app.
Integrated Authentication is an SDK feature that allows a developer to achieve Single Sign On for their app's web requests. The user's client certificates are automatically passed to an endpoint that challenges for Certificate authentication. By doing so, it is no longer necessary for the developer to manually handle the authentication for an endpoint or prompt a user for credentials.
Single Sign-On, SSO
(Wikipedia, https://en.wikipedia.org/wiki/Single_sign-on)
Benefits
Benefits of using single sign-on include:
- Mitigate risk for access to 3rd-party sites ("federated authentication") because user passwords not stored or managed externally
- Reduce password fatigue from different username and password combinations
- Reduce time spent re-entering passwords for the same identity
- Reduce IT costs due to lower number of IT help desk calls about passwords
SSO shares centralized authentication servers that all other applications and systems use for authentication purposes and combines this with techniques to ensure that users do not have to actively enter their credentials more than once.
Criticism
The term reduced sign-on (RSO) has been used by some to reflect the fact that single sign-on is impractical in addressing the need for different levels of secure access in the enterprise, and as such more than one authentication server may be necessary.
As single sign-on provides access to many resources once the user is initially authenticated ("keys to the castle"), it increases the negative impact in case the credentials are available to other people and misused. Therefore, single sign-on requires an increased focus on the protection of the user credentials, and should ideally be combined with strong authentication methods like smart cards and one-time password tokens.
Single sign-on also makes the authentication systems highly critical; a loss of their availability can result in denial of access to all systems unified under the SSO. SSO can be configured with session failover capabilities in order to maintain the system operation. Nonetheless, the risk of system failure may make single sign-on undesirable for systems to which access must be guaranteed at all times, such as security or plant-floor systems.
Furthermore, the use of single-sign-on techniques utilizing social networking services such as Facebook may render third party websites unusable within libraries, schools, or workplaces that block social media sites for productivity reasons. It can also cause difficulties in countries with active censorship regimes, such as China and its "Golden Shield Project," where the third party website may not be actively censored, but is effectively blocked if a user's social login is blocked.
Security
In March, 2012, a research paper [Rui Wang; Shuo Chen & XiaoFeng Wang. "Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services"] reported an extensive study on the security of social login mechanisms. The authors found 8 serious logic flaws in high-profile ID providers and relying party websites, such as OpenID (including Google ID and PayPal Access), Facebook, Janrain, Freelancer, FarmVille, and Sears.com. Because the researchers informed ID providers and relying party websites prior to public announcement of the discovery of the flaws, the vulnerabilities were corrected, and there have been no security breaches reported.
In May 2014, a vulnerability named Covert Redirect was disclosed. It was first reported "Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID" by its discoverer Wang Jing, a Mathematical PhD student from Nanyang Technological University, Singapore. In fact, almost all[weasel words] Single sign-on protocols are affected. Covert Redirect takes advantage of third-party clients susceptible to an XSS or Open Redirect.
In December 2020, flaws in federated authentication systems were discovered to have been utilized by attackers during the 2020 United States federal government data breach.
Privacy
As originally implemented in Kerberos and SAML, single sign-on did not give users any choices about releasing their personal information to each new resource that the user visited. This worked well enough within a single enterprise, like MIT where Kerberos was invented, or major corporations where all of the resources were internal sites. However, as federated services like Active Directory Federation Services proliferated, the user's private information was sent out to affiliated sites not under control of the enterprise that collected the data from the user. Since privacy regulations are now tightening with legislation like the GDPR, the newer methods like OpenID Connect have started to become more attractive; for example MIT, the originator of Kerberos, now supports OpenID Connect.
Email address
Single sign-on in theory can work without revealing identifying information like email address to the relying party (credential consumer), but many credential providers do not allow users to configure what information is passed on to the credential consumer. As of 2019, Google and Facebook sign-in do not require users to share email address with the credential consumer. 'Sign in with Apple' introduced in iOS 13 allows user to request a unique relay email each time the user signs up for a new service, thus reducing the likelihood of account linking by the credential consumer.
Single Sign-On with Client Certificates
Use
The AS ABAP enables you to configure the use of client certificates for SSO when users access the system from an SAP GUI.
For SAP GUI authentication with client certificates, the security context for authentication is made available from the GSS API of the AS ABAP system. Therefore, to enable the use of client certificates for SSO, the AS ABAP system must be configured to use SNC.
Integration
The use of client certificates for logon with the SAP GUI makes use of public-key cryptography and the AS ABAP Personal Security Environment (PSE) for establishing the user identity. The client certificate information, however, is used only for authenticating SAP GUI users. Transport layer security, the integrity and confidentiality of the authentication credentials is enabled by the SNC used on the AS ABAP.
Prerequisites
To enable SAP GUI SSO with client certificates, users must possess valid client certificates. SAP GUI users can receive client certificates from an established Public-Key Infrastructure.
The SAP GUI client computers and the AS ABAP systems must use SAP NetWeaver Single Sign-On or an external security product that enables the creation of a Personal Security Environment (PSE). The use of an external security product is enabled by Secure Network Communications (SNC).
Note
You can use external security products for client certificate authentication that are certified by the SAP Partner Program. For more information about the SAP certified security products, see http://service.sap.com/securityInformation published on SAP site.
Activities
To enable users and AS ABAP systems to use SSO with client certificates, you must:
- Prepare the central instance.
- Activating SSO on the SAP Logon.
- Import the user's public-key certificates to the AS ABAP.
Banking Identity Act
(Bank Identity Bill, https://www.epravo.cz/top/clanky/navrh-zakona-upravujici-podminky-pro-vznik-bankovni-identity-110488.html)
What is the concept of banking identity?
Banking identity will be a tool that will be used for digital verification of the identity of bank clients (natural persons and legal entities, or their representatives who are natural persons) using security methods that enable their electronic banking. This tool will also offer Czech citizens and legal entities who use Internet banking the opportunity to connect to e-Government services and online private sector services. While bank and government clients will be able to verify digital identities free of charge, various digital service providers will pay verification fees to banks and branches of foreign banks to identify their clients. The participation of banks and branches of foreign banks in the project will not be mandatory and will take place on a voluntary basis.
In addition to the fact that the proposed regulation allows the opening of the market for electronic identification services, there will also be a change in the functioning of the so-called National Point for Identification and Authentication (hereinafter "NIA") in relation to banks and branches of foreign banks.. In order for the project to work successfully, the bill also regulates the access of banks and branches of foreign banks to the basic registers of the Czech Republic. Access will be limited so that banks and branches of foreign banks will be able to more effectively prevent money laundering and terrorist financing, as well as prevent cases where the bank's identity could be misused.
References
- [1] Oracle9iAS Single Sign-On Administrator's Guide
- [2] VMWare Core Capability: Single Sign On Certificate Authentication
- [3] Wikipedie: SSO
- [4] SAP
- [5] Justice, CZ