[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.
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]