Issue #129 resolution: support other external middleware

[exedor]

Changed samlsp/middleware.go to move the request handling part of the RequireAccount method out into a separate public method attached to the middleware type which can be used as a stand alone HTTP RequestHandler. That way the Handler can be used with other middleware chains which provide their own http.Handler wrapper methods.

[bjm88]

Hi, +1 to this, plan to merge? Trying to set things up with GIN framework for spring has been hard. Would this PR help this... #185

[BryceDFisher]

This would be good

[bjm88]

great! can we get merged to master/release?

[crewjam]

thanks, folks!

[bjm88]

thank you! Is there anything else necessary to have this master version used in go get/go.mod or it will be the default?

[crewjam]

It is the master branch, go get should pull it. (I'm not sure about go.mod)

[bjm88]

cool, it would be good if someone can update the read.ME related to this for SPs in initial section "Getting Started as a Service Provider" to show how to use another external web framework like GIN which is very popular. Thanks!

[bjm88]

so I spent some time really digging into this....I think a few issues if anyone still willing to update this library or stumble upon it and perhaps avoid until updated. Unfortunately the go community is lacking big time a good SAML library that is clean and separated from any http, web, or go.http specifics. We really just need an isolated SAML library that can generate xml metadata, initiate SAMLRequests, and consume and validate SAMLResponses. This would allow any application to integrate it how it needed to.

I found even after this fix many other issues hooking up to our existing application with GIN framework. This is a nice library that wanted to make it totally easy to try out SAML, but think if it had more separation of concerns it could be much more broadly used. Perhaps simple refactoring and documentation updates could achieve that.

Issues for SP setup:

1. In saml options cannot pass the consumer URL, it assumes some ~/saml/acs root. This is not good for multi tenant envs that need to work with binding to other params for a given tenant or other use cases. Just let it be configurable or not require it and let developer setup the consumer endpoint and pass req, resp to framework or the payload.
2. To verify and map users seems some design around cookies, relaystate, and jwt being used. JWT is interesting as its static analysis, however I'm not sure if this cookie and in memory usage would work in multi server env where response from IDP may come back to different server. Its just not clear. Would prefer app developer owns any state management, just want to verify the SAMLResponse. Relay state and other remembering where to redirect logic us up to application not this library.
3. To initialize this its requiring some HandlerFunc and account mgmt thing. It should be simple to just generate the SAMLRequest and let app manage calling IDP itself or have helper to initiate the POST to IDP in simplest way without any dependencies. Think this fix got half way there.

[exedor]

Ben, sorry for the delay. I had all the same issues. This patch was specifically to allow me to use this in a multi-tenant environment. It solved the problem pretty much the way you described but certainly doesn't make the integration between your middleware and this client a one-liner.

Additionally, I don't believe what you are suggesting is very practical due to the way SAML authentication works. Any SAML library is going to need to manage the HTTP communication between SP and IDP. Expecting that burden to fall on the application would be far worse. The nature of SAML kind of requires any SAML implementation to manage that.

This patch does allow you to bypass the built-in middleware processing, provide a request and a response to the SP instance, and go from there. I don't know enough about GIN because it was too heavy for my needs. I needed a lean mean fast thin tier for managing OAuth, SAML, and our own internal authentication which is why I selected vestigo. It's simple and doesn't have loads of features I'll never use.

Now, I'm not trying to sell vestigo. Gin is a great framework to be sure. I did take a cursory look at how to integrate it with GIN. It can be done, much in the same way I did mine. If I provide you some source code so you can see the approach, I'm hoping that you know GIN well enough to translate. Here is what I did:

1: On application startup
a) retrieve from data store, the list of all SAML enabled tenants
b) setup SamlSP instances with samlsp.New, passing in samlsp.Options for each tenant
c) configure redirects for use after successful saml authentication (i.e. a tenant root URL)

At this point, all certificates, keys, and SAML properties have been retrieved and configured and are ready for use.

I added these routes:
MyRouter.Get(urlAuthPath+"/:tid/saml/metadata", mysaml.GetSPMetadataReq) MyRouter.Post(urlAuthPath+"/:tid/saml/acs", mysaml.GetSPMetadataReq) MyRouter.Get(urlAuthPath+"/:tid/saml/bridge", myaml.AuthenticateReq)
Now, urlAuthPath is the path from root of my app's authentication system (could just as easily be an empty string if tenant ID is your root path) The ":tid" part is a URL parameter. That's where the multi-tenant thing comes into play. It is the ID of the tenant in question. The "mysaml" package has functions that do the integration. It is almost 400 lines long. I can't post it all here for security and IP reasons, but I can provide the steps I took and some code:

Here is the mysaml.GetSPMetadataReq methods (but the /metadata URL many IDPs don't even use):
// GetSPMetadataReq proxies the requests for /saml/metadata and /saml/acs to samlsp middleware func GetSPMetadataReq(resp http.ResponseWriter, req *http.Request) { tenantID := vestigo.Param(req, "tid") samlSvcProvider := samlSvcProviders[tenantID] if samlSvcProvider == nil { resp.WriteHeader(http.StatusNotFound) return } samlSvcProvider.ServeHTTP(resp, req) }

I provided to the IDP, our URL where users should be redirected after authenticating. It is:
https://mydomain.tld/path/:tid/saml/bridge
where :tid is the ID of the tenant acting as IDP for our application. For example:
https://mydomain.tld/path/32810421/saml/bridge for one tenant.
I use that path for two things:
1: Our application sends unauthenticated users to that URL (when tenant is SAML enabled)
2: The IDP from the tenant sends users to that URL after successful authentication.

Case #1 is easy enough to spot in the form of a missing JWE (we use fully encrypted JWT). I'm guessing you would be using GIN's session management. This addresses your point #2 above. If that happens then I do this:
samlSvcProvider.RequireAccountHandler(resp, req)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That right there is what made all this possible. and pretty much what I think you were alluding to in your first point. It takes a response and a request and based on the SAML config I setup on app initialization, has already been configured with the URL of the IDP where the user should be redirected.

Case #2 is handled after successful authentication by the IDP. That is easy enough to spot by calling this:
samlSvcProvider.IsAuthorized(req)
If that returns true, than this where I create a new JWE and establish our own application's "state" as you call it. I create a session of our own, which for you, I assume would be a GIN session of some kind.

From that point forward the user looks just like any other user from any other tenant.

I have no idea why you are asking to manage calling the IDP in point #3 above. That certainly isn't a separation of concerns and based on what I know about the SAML protocol, I am almost certain you would want no part of it. In fact, handing that over to the app developer would make what you are trying to accomplish harder, not easier.