c# - Building a security library, I think I'm overbuilding it -

so i'm building custom security library, interfaces our database. it's supposed provide basic access control in-house apps: users can x, others can't. needs @ moment pretty basic, library used several apps , control lot of securables.

my basic object model user member of 0 or more groups. groups bestow 0 or more permissions. in reality these one-to-many don't want referentially enforce that. permissions grant-only (if no groups give permission, don't have it, there isn't "deny" overrides granted permission in windows rbs), , groups can nest (a tier 2 user has rights of tier 1, plus new ones). when attempting access securable area of program, application imperatively assert user has requisite permission via examining group hierarchy.

however, want there several levels of redundancy built library. of particular importance user doesn't have permission change security settings shouldn't able to. so, want make security hierarchy readonly in cases, needed denied permission can't added in-memory. when user has proven have permission modify security settings providing readonly user permission, should properties become settable code level.

that's think i've overbuilt it. in order this, domain has developed split personality; 2 copies of each of objects, 1 readonly, other not. readonly version 1 produced default; operation produce writable version requires logged-in user have permission make security changes. resulting in 2 users (user , configurableuser), 2 groups, 2 permissions, each 2 interfaces (the configurable deriving readonly)... idea.

i've realized people cruft stop other developers, trustworthy (it's in-house app , control resources app makes use of, , developers admin rights on lot). if can trust people touch code know they're doing, apps can read-write , there won't problem possibility permissions can "elevated" via clever code snippet.

help me make sane. there different pattern should follow? right distrust other developers? prefer not integrate windows security, option has been discussed; main drawback access rights maintained in active directory entire company, , manager of users of app shouldn't have kind of access overall system security.

edit: comments , answers all. ad or other integrated security not totally off table, did discuss before started developing, , found drawbacks. so, here more of my/our thoughts on why decided go "custom" security setup:

• use of app entirely in-house. such, security of app not preventing outside attacks/hostile takeovers, keeping joe officeworker doing shouldn't according business policy. if joe ends miraculously finding way make himself "god" in app, powers still pretty limited, because app has limited access database , other resources, of he'd need job anyway , granted virtue of being lowest-level user.

• despite that, if user ever got windows password phished, cracked or keylogged, attacker gain serious access client data through application "free" if app used integrated security instead of traditional login. separate security layer app provides @ least possibility of redundancy; they'd have crack 2 sets of credentials in instead of one, , second set of credentials locked behind yet layer of database security cracked user wouldn't have free access to.

• using active directory or other integrated security has couple of problems development/administrative perspective.

  1. first, members of department "swap desks" , things on each others' computers quite bit. integrating windows security requires users log way out of os change app's current logged-in user, instead of closing, reopening , logging app different user.
  2. second, manager of department using software logical person handle security permissions within app, not logical person whom give ad admin access. balancing require layer of roles within ad provide "sub-admin" access ad, grant rights people. there documented requirement security management integrated app, imo makes ad integration infeasible.
  3. lastly, windows integrated security understand doesn't have "permission" layer. instead of asserting user has stated permission something, assert user in particular role, inference being that role has permission continue. can either develop system requiring ad have role every specific securable in app, nested logical roles users have (an administrative nightmare i'm sure network admin fight keep out of security layer), or define broad swaths of functionality belong known role, nest roles create "user levels", , if user ever needs access 1 piece of functionality next level up, have whole level (or ad , app have changed separate functionality specific assignable role).

the simple solution, given this, contain security within bounds of app instead of tying in network security. security structure can maintain relative ease, stops @ app.

edit 2: epilogue question, solution arrived @ keep mutable object hierarchy, create simple interface, iauthuser, readonly members user's basic info , permissions. iauthusers created in 1 place - during login - copying user retrieved using credentials private class implements public interface. used authentication , authorization interrogating contained list of permissions projected user's group membership @ startup. never turned mutable users, , never saved db. meanwhile, mutable users cannot turned iauthusers outside of login process, useless authorization, , cannot saved db without providing iauthuser has permission make type of changes detected in object (by comparing version in db)

instead of having split hierarchy, have "user can modify security settings" permission, , assert time user tries edit something.