Category:Attack Categorisation By Attacked Single Sign-On Component: Difference between revisions

From Single Sign-On Attacks
Jump to navigation Jump to search
(Created page with "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 diffe...")
 
No edit summary
Line 1: Line 1:
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. <br>
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. <br>
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. <br>
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. <br>
As can be seen in the Figure 1, the Service Provider contains the different security-related components:
As can be seen in Figure 1, the Service Provider contains the different security-related components:
*'''Client''' (a user communicating with an ''SaaS-CP'' via his UA, for example, a web browser. The communication takes place via the HTTP Protocol.);
*''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
*''Web Frontend''(for example, a web server listening on a specific port and forwarding the traffic to the according handlers)
port and forwarding the traffic to the according handlers);
*''Username/Password'' module manages the corresponding authentication and the password-recovery mechanism
*'''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)''
*'''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
*'''SSO module''' carries out the verification of the received authentication
tokens and contains three internal modules:
tokens and contains three internal modules:
     '''The Parser''' (converts an input string into data objects, which can then be further processed by following components)
     '''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)
     '''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)
     '''Processor''' (after the verification, the information regarding the authenticated user will be extracted from the token and forwarded to the business logic)
*'''Authorization & Access Management (AAM)''' controls the access to the restricted resources;
<br> '''These internal modules are considered as potentially violated targets'''.
*'''User Database''' stores information about users and their credentials;
*''Authorization & Access Management (AAM)'' controls the access to the restricted resources
*'''Resources''' include the entirety of data accessible to registered users.
*''User Database'' stores information about users and their credentials
*''Resources'' include the entirety of data accessible to registered users

Revision as of 18:31, 26 January 2016

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