Well, I'm not totally sure I understand what you're asking. But the security work I did in 2.0 specifically punts the question of authentication to the owner process. Meaning, if you can set Thread.CurrentPrincipal before you call in to the FlexWiki stuff, it should Just Work. Probably the easiest way to do this is to rip the head off of the (essentially trivial) forms authentication support built in to FlexWiki (the stuff I just added) and add your own. I.e. write your own login.aspx and make sure you add the user to whatever groups they need to be in, then use the AllowRead and DenyRead stuff to assign topic permissions to those roles. Make sense?
If you get really screwed and need deeper integration, then I think I'd push you towards doing a private build. Before you get too scared, realize that the rearchitecture allows you to insert interceptors into the processing chain that should let you augment the security stuff with the logic you suggest. It's not currently pluggable because I didn't add the hooks to look in a config file, but that would be pretty easy to change. Then you'd have a place to put stuff like this, and a way to stay synchronized with changes moving forward. Hopefully, though, we can figure out a way to make it work the way it is now. That's going to be the easiest thing. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:flexwiki- > [EMAIL PROTECTED] On Behalf Of Jimmy Sieben > Sent: Monday, April 09, 2007 9:22 PM > To: FlexWiki Users Mailing List > Subject: [Flexwiki-users] FW 2.0 Security Integration Question > > We have an internal app here that we would like to integrate with > FlexWiki. The idea is that we would have a IE control in the .Net app > that shows a custom view of some wiki pages. The implementation for > this > is pretty straightforward, but we recently hit upon a snag: our > internal > app has its own security model. > > The issue is that certain pieces of data in the app are marked private, > and can only be viewed by a set of users (defined per-item). We would > like to be able to add the capability for FlexWiki to check our app's > security database to restrict access to the corresponding wiki pages. > > I'm curious what the feasibility of this would be? Ideally, we would > like to use the built-in security provider for most of the pages, but > on > a per-page basis layer on top of it the means to secure a page using a > user/role list that comes from our app's database. Roughly, I am > thinking of something where the wiki looks for a property named > something like _CustomSecurityProvider that understands how to check > the > internal database first and then fallback to the wiki provided security > if nothing was specified. > > Being an internal app, we can assume that the usernames will match (we > are using Active Directory for wiki auth, and can assume that the > internal app will use the same names). > > Does this sound feasible? Any other issues that might come up? ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
