User Tools

Site Tools


network_stuff:sso

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
network_stuff:sso [2022/12/20 21:02] jotasandokunetwork_stuff:sso [2024/12/19 22:08] (current) jotasandoku
Line 1: Line 1:
-\ 
-APACHE\\: 
-Config files, in /etc/apache 
-  conf-available # is more for Virtual-Host settings (subdomains, http/https)  
-  conf-enabled 
- 
-  sites-available # and the config-folder is for module configuration (can be as well webservices like owncloud or phpmyadmin that are available on a subfolder 
-  sites-enabled 
- 
-  mods-available 
-  mods-enabled 
- 
- 
-Apache logs are here: 
-  tail /opt/observium/logs/access_log  
----- 
- 
- 
-  
- 
-- To generate SSO, we have  apache virtual host like the one attached. if we want to use an API and override the SSO, we can add another virtual host. Location is /etc/httpd/conf.d/observium.conf 
-{{ :network_stuff:sso_example1.txt |}} 
-\\ 
-SSO notes:\\ 
-There's a double authentication, one from the user with google + one from apache to google (after that)\\ 
-{{ :network_stuff:oob_dia1.jpg?200 |}} 
- 
- 
----- 
- 
 **SAML-SSO vs OAUTH-SSO**: **SAML-SSO vs OAUTH-SSO**:
 \\ \\
 What is and Identity Provider [[https://www.cloudflare.com/en-gb/learning/access-management/what-is-an-identity-provider/|IdP]]? What is and Identity Provider [[https://www.cloudflare.com/en-gb/learning/access-management/what-is-an-identity-provider/|IdP]]?
- 
 \\ \\
- +OpenID and SAML are  associated with federated services, 
-OAuth:+\\ 
 +**OAuth**:
 \\ \\
  
Line 44: Line 14:
 Google responds with the appropriate information, such as the email address and real name of the user for which that code is valid. Google responds with the appropriate information, such as the email address and real name of the user for which that code is valid.
 The SP then creates a local session associated with that information. In the case of Apache's mod_auth_openidc it then makes the email address etc. available and they can then be sent to applications running behind Apache. The SP then creates a local session associated with that information. In the case of Apache's mod_auth_openidc it then makes the email address etc. available and they can then be sent to applications running behind Apache.
- 
 \\ \\
 However this solution does not work for CompanyY because machines may wish to use SSO but not be allowed to connect directly to the IdP service, or indeed, may be physically unable to connect because the segment colour does not allow connections out, for example. So instead CompanyY uses SAMLv2 for SSO. However this solution does not work for CompanyY because machines may wish to use SSO but not be allowed to connect directly to the IdP service, or indeed, may be physically unable to connect because the segment colour does not allow connections out, for example. So instead CompanyY uses SAMLv2 for SSO.
 \\ \\
  
-SAMLv2:\\+**SAMLv2**: 
 +\\
  
 SAMLv2 is similar to OAuth, except that all of the data is handled by the browser. Many of the steps are similar or approximately equivalent. SAMLv2 is similar to OAuth, except that all of the data is handled by the browser. Many of the steps are similar or approximately equivalent.
Line 61: Line 31:
 If valid then the appropriate credentials e.g. email address, are made available and the SP can manage those. In the case of Apache, for example, the email address is inserted into the X-REMOTE-USER variable for use by backend applications. If valid then the appropriate credentials e.g. email address, are made available and the SP can manage those. In the case of Apache, for example, the email address is inserted into the X-REMOTE-USER variable for use by backend applications.
 {{:network_stuff:saml-vs-oauth.jpeg?600|}} {{:network_stuff:saml-vs-oauth.jpeg?600|}}
 +
 +
 +
 +SSO Using OAuth (OAuth 2.0)
 +
 +    User → SP: User tries to access a resource.
 +    SP → IdP: SP redirects the user to the IdP (Authorization Endpoint).
 +    IdP ↔ User: IdP authenticates the user.
 +    IdP → SP: IdP provides an Authorization Code to the SP via the browser.
 +    SP → IdP: SP exchanges the Authorization Code for an Access Token.
 +    SP → Resource: SP uses the Access Token to grant the user access.
 +
 +SSO Using SAML
 +
 +    User → SP: User attempts to log in or access the SP.
 +    SP → IdP: SP redirects the user to the IdP with a SAML authentication request.
 +    IdP ↔ User: IdP authenticates the user and generates a SAML assertion.
 +    IdP → SP: The user submits the SAML assertion to the SP.
 +    SP → Resource: SP validates the SAML assertion and grants access.
 +    
 +    
 +----
 +
 +APACHE\\:
 +Config files, in /etc/apache
 +  conf-available # is more for Virtual-Host settings (subdomains, http/https) 
 +  conf-enabled
 +
 +  sites-available # and the config-folder is for module configuration (can be as well webservices like owncloud or phpmyadmin that are available on a subfolder
 +  sites-enabled
 +
 +  mods-available
 +  mods-enabled
 +
 +
 +Apache logs are here:
 +  tail /opt/observium/logs/access_log 
 +----
 +
 +
 + 
 +
 +- To generate SSO, we have  apache virtual host like the one attached. if we want to use an API and override the SSO, we can add another virtual host. Location is /etc/httpd/conf.d/observium.conf
 +{{ :network_stuff:sso_example1.txt |}}
 +\\
 +SSO notes:\\
 +There's a double authentication, one from the user with google + one from apache to google (after that)\\
 +{{ :network_stuff:oob_dia1.jpg?200 |}}
 +
  
network_stuff/sso.1671570137.txt.gz · Last modified: (external edit)