Re: [saml-dev] Looking for feedback on a first SAML implimentation.

Scott,

Anything that can be bundled in to a WAR file, with no addtional server work, is totally fine with me. A quick google search for: SAML filter lead me to this:

http://www.softwareborsen.dk/projekter/softwarecenter/brugerstyring/oio-saml-java

If you know of anything else, or any other places I might look (alread looked here: http://saml.xml.org/products), I'd love to hear about it.

Did I say thanks yet? Well, thanks again!

-Morgan

On Tue, Dec 23, 2008 at 2:49 PM, Scott Cantor <> wrote:

> My motivation for doing a code-based solution, rather than a server-add-on

> solution is ease of deployment.

Well, there's easy for the guy who wants to do it exactly the way you start

out assuming it should be done, and then there's easy for the inevitable

second guy who gets asked by his boss to do it differently. It's the second

guy I'm thinking about.

> I'd really like to have everything contained

> in a single application which can be deployed entirely within a WAR file

> (standard java webapp packaging), using the standard techniques we now

use,

> rather than having to make requests of a sysadmin to install/configure a

> server.

A Java filter-based approach to supporting SSO is still contained within the

WAR, but it can, if done properly, insulate the aplication itself from any

dependency on that particular filter.

So there's still a basic disconnect between API and filter-based designs,

and I am extremely biased about that particular issue.

> I'd also like for this app to be easily portable across different server

> technologies, and not require someone working with it in the future to

know

> about special configurations on the server.

I think you give up important flexibility there, FWIW. You're still going to

have to configure all the code you baked into the application to do what you

need, so I don't think it makes all that much difference in the long run,

but that's just my opinion.

> For a complex system, I can

> easily imagine benefits to making the application "agnostic to the form of

> authentication", but wonder if, for my simple purposes, those benefits

might

> be outweighed by the additional deployement/configuration complexity.

The advantage of that approach is not proportional to the complexity of the

application. In fact, I would argue the opposite if anything, since complex

apps often can demand significant effort when changes are required without

raising questions, where simple apps might be viewed as unworthy of any

effort. So the time comes to change them, and nobody wants to invest the

effort because they were so small to begin with. I have direct experience

with that.

> It sounds like the "right" way to use SAML is the way you folks have

> outlined, and if that's too elaborate for my situation, SAML itself may be

a

> more powerful/complex tool than I need.

There's no right or wrong way, the issue of embedding things inside

applications vs. insulation and layering is orthogonal to SAML or any other

SSO technology. As you can easily tell, I have very strong feelings about it

from my background supporting developers at a large university. We require

the ability to change our infrastructure without changing applications

because getting resources to change applications is almost impossible.

Specific SAML implementations will almost certainly be complex for you to

deal with because they are not targeted at making any individual deployment

as simple as possible, but making as many different deployments possible at

once. Others will be more suitable, trading flexibility for ease of use.

-- Scott

-- 
+++++++++++++++++++++++++++++++++++++++
morganpackard.com
myspace.com/morganpackard

finediving.org
anticipaterecordings.com
(646) 206-8337