3 fields

38

13

25 items

https://www.iso.org/information-security/identity-management

https://www.iso.org/information-security/identity-management

https://www.iso.org/files/live/sites/isoorg/files/news/insights/information-security/Info%20sec_Identity%20management.png/thumbnails/1200x600

7 fields

Introduction to Federated Identity and the FedID CG | Federated Identity Community Group

Apr 21, 2022, 12:00:00 AM UTC

The audience for this post is people who are unfamiliar with how privacy concerns may impact federated identity. That likely includes people from one of two groups: 1) people who are interested in privacy, but are new to the concept of federated identity, or 2) people who are familiar with federated identity, but are unaware of the changes being made to browsers because of the privacy concerns. The goal of the post is to provide an introduction to federated identity and why it matters, what the privacy changes are and their potential impact, and then describe how FedID CG is working to preserve federated identity in light of the privacy-related changes. Federated Identity encompasses the technologies, standards, and use cases in which the user identification and user authentication services are separated from the service providing the resource a user is trying to access. The organizations providing the user identification/authentication services are generally referred to as Identity Providers, and the organizations that utilize their services are often referred to as Relying Parties. Federated identity makes it possible for a website, app, and/or API to outsource authentication to an external entity. In practice, users with an account with entity A can gain access to web apps B and C without having to create new usernames and passwords, if B and C outsource authentication. Sometimes referred to as Single Sign-On, or SSO, there is a distinction to be made between SSO and federated identity. SSO is a property of federated identity that makes it possible for a user to gain access to distinct web apps or API without having to reenter credentials. The broader use of federated identity is when the resources involved are located in different security domains and are owned by different organizations. The types of organizations that use federated identity are as varied as the internet. It’s a common practice to use federated identity to streamline account management and access by allowing users to log in with an identity provider account (those “Log in with Facebook”, “Log in with Google”, “Log in with …” buttons.). It’s also commonly used by businesses to manage their employees’ access to company resources. Universities use federated identity to offer students multi-institutional academic programs, to provide shared access to educational resources, and for research collaboration. Federal institutions use federated identity to manage access to federal resources too – as do financial institutions. And for one final example, it’s also frequently used in Software-as-a-Service business models as well. Federated identity significantly reduces the burden on users by limiting account proliferation. It streamlines the user experience, lowers the security risks associated with password re-use (e.g., credential stuffing attacks), decreases the raw number of access credentials that a user has to remember and manage, and facilitates inter-organizational relationships and management. However, linking a user’s identity across systems also raises privacy concerns, especially when done across organizations/entities (and to a much lesser extent even when the resources are all owned by the same organization). While the objective of federated identity systems is to facilitate a user’s access to resources online, it was originally designed on top of web primitives (e.g. third-party cookies, top-level navigations, etc). These primitives can and are being abused to track users without their consent or full understanding. In response to these concerns, user-agents are making changes to how they work with some of the fundamental primitives of the web to prevent the uncontrolled, hidden tracking of users. Since federated identity often utilizes these same primitives to exchange necessary information to complete authentication flows, we need to develop solutions that address these privacy concerns without breaking federated identity. There are a variety of privacy-related interventions that user-agents are exploring. These include deprecating third-party cookies, controlling access to the client’s web storage, removing certain parameters from links (often referred to as link decoration), and restricting the capabilities of navigational redirects. Federated identity often relies on these same mechanisms, and so the changes being made to improve support for end-user privacy are having an effect on federated identity systems. Since the most immediate change is the deprecation of third-party cookies (having already been deployed in Safari and Firefox, and publicly planned for Chrome in late 2023), the Federated Identity Community Group (FedID CG) is currently focusing most of its attention on the impact of that change. The group is working to preserve federation when third-party cookies are deprecated. The FedID CG meets every week to provide feedback on the proposals that are relevant to federated identity. The full charter for the group can be found here . If you’re interested in learning more, we are currently working on a draft report that will be published shortly. If you’d like to participate in the group, you can join FedID CG here . Please note that while a W3C account is required to join, you do not need to be a member of the W3C. If you don’t have a W3C account, you can sign up for one on the W3C account request page .

7 fields

Automated Certificate Management Environment (ACME) Extension for Single Sign On Challenges

Apr 8, 2021, 12:00:00 AM UTC

Abstract This document specifies an extension to the ACME protocol [RFC8555] to enable ACME servers to validate a client's control of an email identifier using single sign-on (SSO) technologies. An extension to the CAA [RFC8659] resource record specification is also defined to provide domain owners a means to declare a set of SSO providers that ACME servers may rely upon when employing SSO for identifier validation on their domain. Authors Andrew Biggs Richard Barnes Moynihan (Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)

7 fields

Single sign-on

Jun 5, 2024, 7:13:50 AM UTC

From Wikipedia, the free encyclopedia Single sign-on ( SSO ) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems. True single sign-on allows the user to log in once and access services without re-entering authentication factors. It should not be confused with same-sign on (Directory Server Authentication), often accomplished by using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases on (directory) servers. [1] [2] A simple version of single sign-on can be achieved over IP networks using cookies but only if the sites share a common DNS parent domain. [3] For clarity, a distinction is made between Directory Server Authentication (same-sign on) and single sign-on: Directory Server Authentication refers to systems requiring authentication for each application but using the same credentials from a directory server, whereas single sign-on refers to systems where a single authentication provides access to multiple applications by passing the authentication token seamlessly to configured applications. Conversely, single sign-off or single log-out ( SLO ) is the property whereby a single action of signing out terminates access to multiple software systems. As different applications and resources support different authentication mechanisms, single sign-on must internally store the credentials used for initial authentication and translate them to the credentials required for the different mechanisms. Other shared authentication schemes, such as OpenID and OpenID Connect , offer other services that may require users to make choices during a sign-on to a resource, but can be configured for single sign-on if those other services (such as user consent) are disabled. [4] An increasing number of federated social logons, like Facebook Connect , do require the user to enter consent choices upon first registration with a new resource, and so are not always single sign-on in the strictest sense. Benefits [ edit ] Benefits of using single sign-on include: Mitigate risk for access to 3rd-party sites ("federated authentication") [5] because user passwords are not stored or managed externally Reduce password fatigue from different username and password combinations Reduce time spent re-entering passwords for the same identity [5] Reduce IT costs due to lower number of IT help desk calls about passwords [6] Simpler administration. SSO-related tasks are performed transparently as part of normal maintenance, using the same tools that are used for other administrative tasks. Better administrative control. All network management information is stored in a single repository. This means that there is a single, authoritative listing of each user's rights and privileges. This allows the administrator to change a user's privileges and know that the results will propagate network wide. Improved user productivity. Users are no longer bogged down by multiple logons, nor are they required to remember multiple passwords in order to access network resources. This is also a benefit to Help desk personnel, who need to field fewer requests for forgotten passwords. Better network security. Eliminating multiple passwords also reduces a common source of security breaches—users writing down their passwords. Finally, because of the consolidation of network management information, the administrator can know with certainty that when he disables a user's account, the account is fully disabled. Consolidation of heterogeneous networks. By joining disparate networks, administrative efforts can be consolidated, ensuring that administrative best practices and corporate security policies are being consistently enforced. 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 [ edit ] 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. [7] 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. [7] Single sign-on also increases dependence on highly-available authentication systems; 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. [8] 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. [9] [10] Security [ edit ] In March 2012, [11] a research paper 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. [12] In May 2014, a vulnerability named Covert Redirect was disclosed. [13] 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. [14] [15] [16] 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. [17] 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 . [18] [19] Due to how single sign-on works, by sending a request to the logged-in website to get a SSO token and sending a request with the token to the logged-out website, the token cannot be protected with the HttpOnly cookie flag and thus can be stolen by an attacker if there is an XSS vulnerability on the logged-out website, in order to do session hijacking . Another security issue is that if the session used for SSO is stolen (which can be protected with the HttpOnly cookie flag unlike the SSO token), the attacker can access all the websites that are using the SSO system. [20] Privacy [ edit ] 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 . [21] Email address [ edit ] Single sign-on in theory can work without revealing identifying information such as email addresses 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 addresses with the credential consumer. " Sign in with Apple " introduced in iOS 13 allows a user to request a unique relay email address each time the user signs up for a new service, thus reducing the likelihood of account linking by the credential consumer. [22] Common configurations [ edit ] Kerberos-based [ edit ] Initial sign-on prompts the user for credentials, and gets a Kerberos ticket-granting ticket (TGT). Additional software applications requiring authentication, such as email clients , wikis , and revision-control systems, use the ticket-granting ticket to acquire service tickets, proving the user's identity to the mail-server / wiki server / etc. without prompting the user to re-enter credentials. Windows environment - Windows login fetches TGT. Active Directory -aware applications fetch service tickets, so the user is not prompted to re-authenticate. Unix / Linux environment - Login via Kerberos PAM modules fetches TGT. Kerberized client applications such as Evolution , Firefox , and SVN use service tickets, so the user is not prompted to re-authenticate. Smart-card-based [ edit ] Initial sign-on prompts the user for the smart card . Additional software applications also use the smart card, without prompting the user to re-enter credentials. Smart-card-based single sign-on can either use certificates or passwords stored on the smart card. Integrated Windows Authentication [ edit ] Integrated Windows Authentication is a term associated with Microsoft products and refers to the SPNEGO , Kerberos , and NTLMSSP authentication protocols with respect to SSPI functionality introduced with Microsoft Windows 2000 and included with later Windows NT -based operating systems. The term is most commonly used to refer to the automatically authenticated connections between Microsoft Internet Information Services and Internet Explorer . Cross-platform Active Directory integration vendors have extended the Integrated Windows Authentication paradigm to Unix (including Mac) and Linux systems. Security Assertion Markup Language [ edit ] Security Assertion Markup Language (SAML) is an XML -based method for exchanging user security information between an SAML identity provider and a SAML service provider . SAML 2.0 supports W3C XML encryption and service-provider–initiated web browser single sign-on exchanges. [23] A user wielding a user agent (usually a web browser) is called the subject in SAML-based single sign-on. The user requests a web resource protected by a SAML service provider. The service provider, wishing to know the identity of the user, issues an authentication request to a SAML identity provider through the user agent. The identity provider is the one that provides the user credentials. The service provider trusts the user information from the identity provider to provide access to its services or resources. Emerging configurations [ edit ] Mobile devices as access credentials [ edit ] A newer variation of single-sign-on authentication has been developed using mobile devices as access credentials. Users' mobile devices can be used to automatically log them onto multiple systems, such as building-access-control systems and computer systems, through the use of authentication methods which include OpenID Connect and SAML, [24] in conjunction with an X.509 ITU-T cryptography certificate used to identify the mobile device to an access server. A mobile device is "something you have", as opposed to a password which is "something you know", or biometrics (fingerprint, retinal scan, facial recognition, etc.) which is "something you are". Security experts recommend using at least two out of these three factors ( multi-factor authentication ) for best protection. See also [ edit ] Account pre-hijacking Central Authentication Service Identity management Identity management systems List of single sign-on implementations Password manager Security Assertion Markup Language Usability of web authentication systems References [ edit ] ^ "What's the Difference b/w SSO (Single Sign On) & LDAP?" . JumpCloud . 2019-05-14 . Retrieved 2020-10-27 . ^ "SSO and LDAP Authentication" . Authenticationworld.com. Archived from the original on 2014-05-23 . Retrieved 2014-05-23 . ^ "OpenID versus Single-Sign-On Server" . alleged.org.uk. 2007-08-13 . Retrieved 2014-05-23 . ^ "OpenID Connect Provider - OpenID Connect Single Sign-On (SSO) - OIDC OAuth Authentication" . OneLogin . ^ a b "Single sign-on and federated authentication" . kb.iu.edu . ^ "Benefits of SSO" . University of Guelph . Retrieved 2014-05-23 . ^ a b "Single Sign On Authentication" . Authenticationworld.com. Archived from the original on 2014-03-15 . Retrieved 2013-05-28 . ^ "Sun GlassFish Enterprise Server v2.1.1 High Availability Administration Guide" . Oracle.com . Retrieved 2013-05-28 . ^ Laurenson, Lydia (3 May 2014). "The Censorship Effect" . TechCrunch . Archived from the original on August 7, 2020 . Retrieved 27 February 2015 . ^ Chester, Ken (12 August 2013). "Censorship, external authentication, and other social media lessons from China's Great Firewall" . Tech in Asia . Archived from the original on March 26, 2014 . Retrieved 9 March 2016 . ^ Wang, Rui; Chen, Shuo; Wang, XiaoFeng (2012). "Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services" . 2012 IEEE Symposium on Security and Privacy . pp. 365–379. doi : 10.1109/SP.2012.30 . ISBN 978-1-4673-1244-8 . S2CID 1679661 . ^ "OpenID: Vulnerability report, Data confusion" - OpenID Foundation, March 14, 2012 ^ "Facebook, Google Users Threatened by New Security Flaw" . Tom's Guide. 2 May 2014 . Retrieved 11 November 2014 . ^ "Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID" . Tetraph. 1 May 2014 . Retrieved 10 November 2014 . ^ "Math student detects OAuth, OpenID security vulnerability" . Tech Xplore. 3 May 2014 . Retrieved 10 November 2014 . ^ "Facebook, Google Users Threatened by New Security Flaw" . Yahoo. 2 May 2014 . Retrieved 10 November 2014 . ^ "Covert Redirect Flaw in OAuth is Not the Next Heartbleed" . Symantec. 3 May 2014 . Retrieved 10 November 2014 . ^ "VMware Flaw a Vector in SolarWinds Breach? — Krebs on Security" . 19 December 2020. ^ Kovacs, Eduard (15 December 2020). "Group Behind SolarWinds Hack Bypassed MFA to Access Emails at US Think Tank" . Security Week . Retrieved 19 December 2020 . ^ "What Is Session Hijacking?" . 22 August 2019. ^ MIT IST. "OpenID Connect Authorization" . ^ Goode, Lauren (2019-06-15). "App Makers Are Mixed on 'Sign In With Apple' " . Wired . ISSN 1059-1028 . Retrieved 2019-06-15 . ^ Armando, Alessandro; Carbone, Roberto; Compagna, Luca; Cuéllar, Jorge; Pellegrino, Giancarlo; Sorniotti, Alessandro (2013-03-01). "An authentication flaw in browser-based Single Sign-On protocols: Impact and remediations" . Computers & Security . 33 : 41–58. doi : 10.1016/j.cose.2012.08.007 . ^ "MicroStrategy's office of the future includes mobile identity and cybersecurity" . The Washington Post . 2014-04-14 . Retrieved 2014-03-30 . External links [ edit ] Single sign-on intro with diagrams

8 fields

How does SSO (Single Sign On) work