Category:Attack Categorisation By Attacked Single Sign-On Component

From Single Sign-On Attacks
Revision as of 19:31, 26 January 2016 by Anna (talk | contribs)
Jump to navigation Jump to search

Using authentication via Single Sign-On (SSO) has many advantages over simple Username/Password mechanisms. Whereas for the former, the user has to remember multiple different Username/Password combinations, this overhead can be significantly reduced with SSO. Also, the security of Username/Password relies solely on the strength of the password provided by the user, but SSO allows for the adoption of several technical measures to further enhance the security of the login procedure.
In general, authentication using SSO is done utilizing a trusted third party called Identity Provider (IdP). When a user uses his user agent (UA), e.g., a web browser, to request a login to the service provider (SaaS-CP), instead of asking for Username/Password, the service issues a Token Request and redirects the client to the IdP. After proper authentication, the IdP issues a signed authentication token (Token) and redirects the client back to the SaaS-CP, where the token will be validated and the user logged in.
As can be seen in Figure 1, the Service Provider contains the different security-related components:

  • Client is a user communicating with an SaaS-CP via his UA, for example, a web browser. The communication takes place via the HTTP Protocol.)
  • Web Frontend(for example, a web server listening on a specific port and forwarding the traffic to the according handlers)
  • Username/Password module manages the corresponding authentication and the password-recovery mechanism
  • Session Management (SM) module resolves the received Session Cookies by the Web Frontend to a user identity and forwards this information to Authorization & Access Management (AAM)
  • SSO module carries out the verification of the received authentication

tokens and contains three internal modules:

   The Parser (converts an input string into data objects, which can then be further processed by following components)
   Verificator (validation of all security-relevant parameters within the authentication token)
   Processor (after the verification, the information regarding the authenticated user will be extracted from the token and forwarded to the business logic)

These internal modules are considered as potentially violated targets.

  • Authorization & Access Management (AAM) controls the access to the restricted resources
  • User Database stores information about users and their credentials
  • Resources include the entirety of data accessible to registered users