DokuWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
**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]]?
\\
OpenID and SAML are  associated with federated services,
\\
**OAuth**:
\\

Setup: A project is created with a Unique ID and with the URL to which users are redirected after sign-in to the OAuth provider. That ID is then stored in the SP.
In the case of Google, this uses an OAuth a user connects to the Service Provider (SP) and the SP (e.g. apache) checks if there is a session for the user.
If not then it generates a unique URL containing a locale Unique ID and the IdP project ID, and redirects the user to Google's OAuth service (IdP) to sign in.
Once signed in Google generates a unique URL and redirects the user back to the SP. The SP takes that unique code and sends it to Google directly from the server on which that SP is running.\\
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.
\\
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 is similar to OAuth, except that all of the data is handled by the browser. Many of the steps are similar or approximately equivalent.
\\
Setup: You must download the SSL cert for the IdP and the metadata.xml for the IdP. Next generate a "metadata.xml" containing the SP's SSL Cert and URL to which you want to redirect the user to after sign-in.\\
As before, the user connects to the SP and, if they have no session, then the SP generates a unique code. This time though instead of generating a simple code, the SAML is an XML document is created into which is embedded information about the site making the request and any additional information such as requested information and, of course, a unique code. This SAML response is signed with the IdP's SSL public key so that it can't be tampered with in flight. This SAML document is then Base64 MIME encoded and returned to the browser as part of the response. The response sends back a 301 status code and tells the browser to POST the request to the URL of the IdP  sign-on service. When it does this, the browser includes the SAML response.\\
The IdP then decodes the SAML request, checks the encryption signature and, if valid, prompts the user to authenticate - or if it already knows about the user, considers them to be authenticated.\\
Once successfully authenticated (or already authenticated), the IdP responds to the browser with its own SAML document via a 302 redirect.
Using the POST method the browser sends this SAML document (which is an XML document that is Base64 MIME encoded) to the SP as a HTTP parameter.
The SP decodes the SAML and checks the restrictions. These includes the time window during which it is valid, that the signature should be checked, etc.
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|}}



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 |}}