Conceptual Architecture and Plans for a new FubuMVC.SAML2 bottle

[Jeremy D. Miller]

Extend Health is using SAML2 for authentication more and more often and Corey's volunteered me to help get a new, official FubuMVC.SAML2 bottle going based on some internal work by Mike Murray and Bob Pace.

Corey, if you read this, I'm proposing a little different structure than what we talked about the other day in terms of endpoints.

3 Big Use Cases

1. Allow your system to accept SAML credentials
2. Formulate a SAML authentication request from your system into a separate system
3. Act as an identity provider so that your fubumvc system can generate security tokens for other applications

The big, initial, sure-to-be-wrong proposal:

Right off the bat I think we divide this into 2 or 3 different libraries:

1. FubuSaml2 -- Library that has only a dependency on FubuCore so that it'd be easier to consume in non-fubumvc projects
1. Provide a common object representation for a SAML request with all the defined attributes and children nodes of the SAML xml schema plus the key/value pairs in extensibility
2. Read and write the encrypted & encoded SAML xml messages
3. Provide an in-memory version of the saml model for easier unit testing
4. Handle the x509 certificate handling.  This will have to be a pluggable set of "who knows how to handle this one?" strategies right off the bat based on what I've seen from EH work
5. Will expose the extensible Saml payload attributes in a way that can easily be consumed by fubu model binding so you can pull out strong typed models
6. I looked at the WIF code for reading Saml2 and I'd rather just adapt Mike & Bob's code instead of Microsoft's code unless someone has a different opinion.
2. FubuMVC.Saml2 -- New Bottle to FubuMVC that rides on top of FubuMVC.Authentication, FubuMVC, and FubuSaml2
1. Implements a new IAuthenticationStrategy for fubumvc.authentication, but always orders itself first.  This enables us to accept Saml2 authentication requests on any FubuMVC endpoint from another system and gives us the ability to reuse the existing workflow and redirection in FubuMVC.Authentication.  Also allows you to mix and match saml, windows auth, basic auth, and every other option you can think of for the authentication
2. Pluggable mix and match strategies to simultaneously handle different SAML schemes.  Think different versions of your authentication protocol, clients with "special" needs, and who knows what else.  These strategies will probably be responsible for determining how to redirect or pass through the request (client specific landing page?  go to home?  continue to the requested url?) and probably come into play about how to create new principals or store credentials for later requests.  I'm assuming that you would only have to authenticate once through SAML once
3. Support the SAML Http Post Binding pattern (goofy)
4. Support the SAML Redirect Binding from a query string or form attribute
5. No SOAP support for now (ever?)
6. Optional endpoints for turning your FubuMVC application into an identity provider

My thought is that we'd by able to use the FubuSaml2 library to generate testing payloads for end to end testing on FubuMVC.Saml2.

Timeline:

I'm planning to start seeding the codebase on Monday morning and converting Mike & Bob's code for reading the Saml XML.  Sounds like this needs to be ready quickly, so I'm hoping to have something semi-usable by mid week.  I'll be looking for some OSS Friday help from my Extend Health compatriots too;)

Thoughts, concerns, requests?

[Corey Kaylor]

Sounds good. Excited to see where this goes.

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fubumvc-deve...@googlegroups.com.
To post to this group, send email to fubumv...@googlegroups.com.
Visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.