Yeah I was worried I wasn't making it really clear what we want to do.
Given the existing IIS Authentication of a user, I want to add a custom
authorization handler so that certain pages could be secured by
permissions specified somewhere external (say in a database).
The use case is the following:
In the external app (call it NC), a user views a data record that has an
associated wiki topic. This data record may be secured to a set of users
in NC so that only those users can access the fields in the data record
(this is called marking it private). If the NC data record is private
and it has an associated wiki topic, then the wiki topic should be
private as well. We can assume that usernames match and we will use an
embedded IE control to talk to the wiki (which uses Windows
authentication).
I brainstormed a couple of approaches to solving this problem:
1) Have NC update the wiki topic to change the user list on the
fly (by adding or removing from the AllowRead and DenyRead properties of
the topic)
2) Have FlexWiki check the NC database for security permissions
for a select group of topics.
It seemed like option 2 would be more robust. Option 1 involves parsing
and rewriting topics, and the operation wouldn't be atomic so collisions
would be a possibility. If the operation was made atomic it would be a
decent solution, although there is no guarantee that the topic security
properties would not be edited by a user. I'm not sure which I feel like
would be more complex to implement; option 1 would probably require less
code to write, but there would be more bugs and edge cases to deal with.
Option 2 would of course require some modifications to the core, but it
feels like a cleaner approach that would be simpler to solve.
It sounds like the architecture would make it natural for us to plug in
an authorization handler on top of the existing framework, as an
authorization filter. The real key is that we need a way to make that
authorization filter only enabled on a per-page basis. I can see two
approaches right away:
1) Each time a topic is passed through the authorization filter,
ask the NC database if the topic should have special privacy rules
attached. This would be fully automatic, but the downside of a SQL query
for each topic reference. I don't know how many times this query would
run in typical scenarios. I wonder if we would need to think about
caching the results for performance.
2) Scan topics for special metadata, via a topic property like
_CustomAuthorizationHandler: true or something like that. This should be
quite fast since the topic properties are cached (if I recall correctly)
but the downside would be that NC would need to add this property to a
topic. Of course it only needs to be done once, but it is also somewhat
more fragile.
We already have a private build here so I don't worry about that issue
much, and if we implemented a pluggable architecture it sounds like it
could be useful for others.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Craig
Andera
Sent: Monday, April 09, 2007 9:07 PM
To: 'FlexWiki Users Mailing List'
Subject: Re: [Flexwiki-users] FW 2.0 Security Integration Question
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=DEVDE
V
_______________________________________________
Flexwiki-users mailing list
Flexwiki-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flexwiki-users
-------------------------------------------------------------------------
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
