NT Security Service ( was Re: More deprecations in the security Service )

[jb...@wi.rr.com]

We've done the same thing, but we wrote our own security service that
doesn't use the db at all.  We have a custom NT service that sits on
NT and provides a way to authenticate and get the NT groups that the
user is a member of ( we are running our web application on linux, so
JAAS doesn't really provide us with a way to *remotely*
authenticate/authorize against NT).  So we have only valid NT users
and NT groups used for security in out turbine based applications.

I've been watching jcifs.samba.org to see if they get the ability to
remotely get the groups that a user is a member of from a NT domain.
If you've found a way to do this remotely, we can offer up our
security service ( it is very simple ) to the project for inclusion or
picking apart.

>>>>> On Wed, 9 Apr 2003 07:12:12 -0400 , EPugh@upstate.com said:

> I totally agree that the right approach is to implement the minimal
> set of interfaces the way Henning has marked it down below.
> However, in the interestes of getting something to solve my
> immediate business need, I am going to try and stick with the
> current Turbine user architecture.  My approach is to continue to
> define roles in the various turbine tables.  However, what I want to
> do is when a user either registers/logs in, if they validate against
> NT then they are silently inserted into the Turbine_user table(with
> NO password).  Then when they return, when they log in, if they
> suceed against NT, then their user record is grabbed.

> If that goes well, I will try and map NT groups onto Turbine groups.
> So if I log in, and am part of NT groups: MIS, Marketing, then I
> will be part of the TURBINE_GROUP's MIS and Marketing.

> I will admit, I don't quite grok the groups/roles thing.  It seems
> like users should be part of groups.  And groups are part of
> multiple roles.  However, according to TURBINE_USR_GROUP_ROLE, it
> seems like users are part of both groups and roles!

> At any rate, I am going to start this off in my code tree and try
> and have it completely Cactus tested so when it is ready it will be
> as well tested as possible!

> Suggestions/ideas are welcome!

> Eric

> -----Original Message----- From: Henning P. Schmiedehausen
> [mailto:hps@intermeta.de] Sent: Wednesday, April 09, 2003 4:10 AM
> To: turbine-dev@jakarta.apache.org Subject: Re: More deprecations in
> the security Service


> "Colin Chalmers" <co...@maxware.nl> writes:

>> If we want to go down this road shouldn't/couldn't we utilise JAAS?

> Retrofitting JAAS on the Security Service would IMHO a waste of
> time. The only really working way would be (IMHO) to factor out a
> baseline of security interfaces and methods that the Turbine core
> needs from the security service and rebuild it like this

> JAAS Service ---------\ +---- minimal set of interfaces <----- Used
> by the Turbine Core Security Service -----/

> and then design a JAAS based Service without all the overhead from
> the Security Service.  The current set of methods from the
> SecurityService interface is much too heavily based on our current
> User/Group/Role/Permission scheme and the Turbine core uses
> TurbineSecurity.<xxx> all over the place.

> I personally would like to see the pipeline get picked up first. I
> have a feeling that many of the JAAS ideas would be much easier
> implemented once we can "plug" our modules together dynamically.

> 	Regards Henning

> -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/

> Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance
> consultant -- Jakarta Turbine Development -- hero for hire

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

-- 
=====================================================================
Jeffrey D. Brekke                                   jbrekke@wi.rr.com
Wisconsin,  USA                                     brekke@apache.org
                                                    ekkerbj@yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org