It sounds like you are releasing a demo for general consumption that supports JAAS? In this case, you are correct that tying it to NT would limit the number of people who could run it. The way I see it is that you have a couple of options:
1) Write a proprietary JAAS implementation that isn't tied to any native service. Design your implementation so that the interfaces are robust and the API calls make sense for more complex environments, but the actual implementation would be very simple since it's a demo and has to work for everyone. This way when they buy your software, you could then build a custom security implementation for them that ties into whatever they already have. (I see several good things here.. they'll like it because it'll work with their stuff and you'll like it because you get to make more money in a service contract). 2) Ship the demo with a number of different JAAS implementations that the customer can choose from (kinda like how Torque can work with different databases, your demo would work with different security systems). Then just write a configuration tool that lets the customer choose the implementation they want to try. Make sense? -----Original Message----- From: Rodrigo Reyes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 11, 2003 4:48 PM To: Turbine Users List Subject: Re: replacing security service with JAAS OK. Hope I get it right this time. Thanx. Still, the problem I found about having a demo working with NT is that we will be limiting the "out of the box" demo audience to people who have a working NT server (workstation?). I understand that it should be no problem to have it working with other authentication technologies (no business rules code change, right?), but even then there would be extra steps for someone without the NT environment. Wouldn't it be easier for those users if we used some other (more universal) technology? It would be a step less, wouldn't it? Rodrigo ----- Original Message ----- From: "Clifton, Ryan" <[EMAIL PROTECTED]> To: "Turbine Users List" <[EMAIL PROTECTED]> Sent: Tuesday, February 11, 2003 7:22 PM Subject: RE: replacing security service with JAAS > I think you may be a bit confused on what JAAS is/does. JAAS IS the independent security technology you are speaking of. When broken down, it amounts to a bunch of interfaces that allow it to be implemented into a wide variety of environments. So, for example, you can make a JAAS demo working with NT. JAAS itself has nothing to do with NT (thank god), the purpose behind the API is to present a standard way of handling security to client applications (your business logic). If implemented with a bit of forethought, that JAAS demo working under NT could be ported to some other security mechanism and the business logic of the demo should not have to change. > > Just to make sure I said that clearly, I'll explain it a different way. Imagine you write a JUnit test called SecurityTest.java. SecurityTest makes a bunch of calls to your JAAS implementation that validates users and does other neat things that JAAS provides. SecurityTest shouldn't know/care how this particular JAAS implementation works, so that if you re-implemented it to work with Oracle and a user DB, SecurityTest's tests would still run perfectly. > > Hope that helps a bit.. > > -----Original Message----- > From: Rodrigo Reyes [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 11, 2003 4:06 PM > To: Turbine Users List > Subject: Re: replacing security service with JAAS > > > I am a bit new to JAAS, but I thought JAAS would let us build a security > service independent of the authentication technology used behind. Am I > right? Another question: Is your tutorial winNT dependent? If it is, I > propose finding a universal authentication technology, so any one could use > the service, no matter where they run it. Hope there is one :) > > Rodrigo > > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, February 09, 2003 5:30 PM > Subject: RE: replacing security service with JAAS > > > > I wouldn't mind collaborating. I have a JAAS tutorial where I can query > if > > a username/password/domain exists in NT. It seems to work quite well. I > > would like to use it as the first step in authenticating a user. > > > > Eric > > > > -----Original Message----- > > From: Rodrigo Reyes [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, February 08, 2003 9:34 AM > > To: Turbine Users List > > Subject: Re: replacing security service with JAAS > > > > > > I am interested in working on that. > > I read the JAAS tutorial (I was looking for a service like this a > while > > ago, but I couldn't find it until you menction it here) and it looks > > flexible enough to me. I haven't used the security service Turbine > provides > > because it is tightly integrated with Torque, and I am not using Torque. > But > > it seems it wouldn't be that hard to have Torque working with JAAS, and it > > would also give other technologies the oportunity to colaborate in Turbine > > Security. > > You may already know about this, but I will mection it here just in > case > > you don't. There is a service how-to for Turbine at > > http://jakarta.apache.org/turbine/turbine-2.3/howto/services-howto.html. > It > > doesn't look that hard to build one for JAAS. Maybe we could start with > > that. > > > > Rodrigo > > > > ----- Original Message ----- > > From: "Marc Lustig" <[EMAIL PROTECTED]> > > To: "Turbine Users List" <[EMAIL PROTECTED]> > > Sent: Saturday, February 08, 2003 5:37 AM > > Subject: replacing security service with JAAS > > > > > > > Hi, > > > > > > is there any doc or code available for replacing the default security > > > service and implementing Sun's JAAS ? > > > I like the idea to have a robust and standardized API, instead of the > very > > > inflexible one that is currently integrated in Turbine. > > > If anybody has tried this I'd be interested to know about the amount of > > work > > > that needs to be done. > > > > > > Marc > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
