How does/should the communication happen between S

Question

I understand that the communication between IDP and SP is well defined in standard. I'm wondering what are the ways to make the custom communication happen between standalone SP and the actual application.

I assume the standard ways exists, without reinventing the wheel my self. But even spring-saml security only talks about "custom mechanism" doesn't say what it is.

Can someone point to me the right direction? I've searched but I'm surprised that it's not written anywhere blogs, tutorials etc. Not even in Shibboleth/Gluu documentation, that part is somehow left alone.

Any help would be appreciated.

Answer 1

The problem essentially boils down to "how can two applications deployed in a trusted network securely communicate with each other in order to exchange security information about a user". It's the same problem SAML solves for applications communicating over untrusted network and it's made easier by the fact that both the authentication point (SP) and the application are under control of the same entity = it's e.g. easier to use symetric cryptography. The SP can in principle communicate with the app using either front-end channel (= through web browser), or back-end channel (= directly between each other over network).

There are different ways to perform the communication (using one, the other, or both channels), most can be implemented using some of the available security products. Here are some ideas:

Both SP and application are sharing the same domain (= user's web browser accesses them on a URL which shares cookies)

• you can configure your SP to store a cookie - a piece of information including e.g. UID and expiration of the authenticated user, the cookie can be encrypted using a shared secret known to both SP and the application. This is approach used e.g. by OpenAM, or Wildfly with shared domain encrypted cookie.
• an alternative of this approach is to send the information about the authenticated user from SP to the application e.g. as an encrypted HTTP POST parameter - similar approach which SAML does, just much more basic.
• same approach could be enhanced by using another secure shared storage - e.g. a database and sending just a reference to a record (e.g. a unique secret session ID)

SP can be used as HTTP proxy for the application

• in this case you can pass the authentication information as an HTTP header to the application, you must ensure that going through SP is the only way the application can be accessed. This is only practical when the SP is part of e.g. a load balancer (e.g. Apache / Nginx plugin).

SP and application could use a standard authentication mechanism to communicate the authentication data

• you could use e.g. Kerberos (which is anyway based on shared-secret encryption) or OAuth

Each of the option might have different attack vectors and possible vulnerabilities.

My opinion is that adding SAML functionality directly into the application, using the HTTP proxy with SAML support, or a standard product which handles the last mile authentication between SP and the application (e.g. OpenAM) is the best way to go. Implementing custom security mechanism might seem easy, but there's a lot of room for making a mistake which leaves the whole solution vulnerable.