OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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 <cantor.2@osu.edu> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]