How does SAML/SAML2 work?

Question

Django

Hello everyone, I came across such a thing as Shibboleth and in general with the integration of SSO (Single Sign On). as I understand it, there are 2 sides IdP (identity provider) and SP (service provider). IdP is already implemented with Shibboleth, but I, in turn, implement SP. There are 2 ways: use a cumbersome bundle that I really don’t like from Shibboleth SP + Tomcat + Apache Http Server and somehow attach my Python / Django service to it, or throw it all in the trash and try to attach the djangosaml2 module to Django. I chose the second option. But all the same, for me it remained a dark forest how everything works. The first stone for which I stumbled in this swamp is metadata. Where does it come from and where is it transmitted, how and with what is it eaten? should it be static or dynamically generated? What other nuances can I encounter?

Answer 1

In general, by the method of pokes and errors, the following algorithm is found out in my understanding (I chose the option with djangosaml2 and I will describe the solution for this particular case). SP gets the metadata, and it can get it both dynamically and statically from a file:

'metadata': {
      'remote': [{
          "url": 'https://ololo-sso.com/Shibboleth.sso/Metadata'
      }],
      'local': [path.join(BASEDIR, 'remote_metadata.xml')],
}

By the way, from a rake, I got an error: 'SPConfig' object has no attribute '_sp_authn_requests_signed' , which can be overcome by specifying the desired key in SAML_CONFIG :

'service': {
    'sp': {
      ...
           "authn_requests_signed": "false",
      ...
    }
}

The metadata contains all sorts of useful and not so useful information, including encryption keys, and url addresses of handlers for various authorization methods.
Further, when going to the authorization page of the SP, the SP itself forms a request based on the IdP metadata and sends this request by redirect through the browser to the IdP login page, for example:

https://ololo-sso.com/Shibboleth.sso/Login

By receiving this request, the IdP will already know where our errant user came from and where he wants to log in. Moreover, if the IdP does not know where to get the metadata from your service, it will find out just from this request, and after successful authorization it will send your user back to your service.
Also, in the vast majority of cases, the IdP must know about the existence of your service in advance, otherwise it will not let you go anywhere.
Further, I have not figured it out yet.