سناریو 3 - طراحی سیستم کنترل دسترسی سفارشی برای نرم افزار اتوماسیون اداری

سلام دوستان عزیز ،
پیش از آغاز فعالیت ، تاپیک "آغاز پیاده سازی طرح ارتقاء سطح علمی - ذکر جزییات" را مطالعه نمایید ،
سناریوی شماره 3 :
در یک نرم افزار اتوماسیون اداری مبتنی بر ویندوز، نیاز است تا یک سیستم کنترل دسترسی سفارشی برای مدیریت کاربران ایجاد گردد. این سیستم باید به صورت Role-Based طراحی شود، در سیستم مذکور باید بتوان مجوزهای کاربران برای دسترسی به یک بخش خاص از نرم افزار و انجام یک عمل را تعیین نمود ،/

مرحله اول : طراحی سیستم و جداول مورد نیاز در دیتابیس

لطفا" نظرات خود را به طور دقیق و با ذکر جزئیات بیان نمایید ،

پیشاپیش از شرکت شما در این بحث سپاسگزارم ،/

پ.ن : مطالبی که از سوی بنده مطرح میشود ، جهت به چالش کشیدن بحث میباشد و بعضا" ممکن است ساده یا با جواب مشخص و معلوم به نظر بیایند ، این بدان خاطر است که قصد بر این است تا این گفتگوها برای افرادی با سطح علمی پایین تر نیز مفید واقع شود و ممکن است این مطالب در ذهن آنها نیز مطرح گردد ، همچنین جهت این است که تمام جوانب نظر شخص شرکت کننده در گفتگو مورد بررسی قرار گیرد،

برای دسترسی به هر بخش در دیتابیس ، در جدول اعضاء ، یک فیلد از نوع bit درنظر میگیریم.
و مقادیر آنها را بصورت زیر پر میکنیم :
به ازای نداشتن دسترسی : 0
به ازای دسترسی کامل : 1

در برنامه ، برای کاربران یک کلاس در نظر گرفته و برای هر قسمت یک متغیر static از نوع bool تعریف میکنیم.
مقادیر این متغیر ها را با توجه به مقادیر متناظرشون در دیتابیس هنگام ورود کاربر به سیستم پر مکنیم.

در آخر در رویداد Load هر فرم ، سطح دسترسی کاربر مذکور را بررسی میکنیم و فعال یا غیر فعال بودن کنترل ها (مثل دکمه ها) را تنظیم میکنیم

به نظرم در Form load اين عمل صورت نگيره بهتره
به اين دليل كه فرم هم لود ميشه و كاربر ميبينه كه فرم به چه صورت هست و بعد پيغام خطا به كاربر نشون داده ميشه - به طور مثال در Btn كه براي ورود به يك بخش است اين عمل صورت بگيره قبل از ورود به اون بخش اينها چك ميشه و خطاهاي احتمالي جلوگيري ميشه.

براي Login هم از abstract استفاده مي كنيم. يك كلاس پدر مي سازيم تا بتونيم ازش كلاس فرزند رو به ارث ببريم. حالا يه كلاس ديگه مي نويسيم كه در حافظه به صورت Dymond هستش و كارش تشخيص Admin يا User يا... بودن كاربر هستش. سپس براي هر عملياتي كه مي خوايم مجوز براش صادر كنيم اين كلاس رو صدا مي زنيم و بر اساس مجوزش عمليات اجرا يا پيام خطا Access Denied مي ده.
باز هم همون قانون برقراره:

Classes: Actor ^ Action

در این کارها یک کاربر چندان ارزشی ندارد. معمولا در سیستم های مدیریت IT باید نقش و گروه تعریف بشود و کاربران را به آن نقش ها نسبت داد و حذف کرد ، در حقیقت باید موجودیت کاربران در سیستم ثابت بوده و نقش آنان عوض شود. حرف ها یکی است اما تفکرات پایه متفاوت است که در کارهای بزرگ به مشکل بر می خورید.
اگر وقت شد بعدا بحث را باز می کنم.

نقل قول:

---

نوشته شده توسط علیرضا مداح

سلام دوستان عزیز ،
پیش از آغاز فعالیت ، تاپیک "آغاز پیاده سازی طرح ارتقاء سطح علمی - ذکر جزییات" را مطالعه نمایید ،
سناریوی شماره 3 :
در یک نرم افزار اتوماسیون اداری مبتنی بر ویندوز، نیاز است تا یک سیستم کنترل دسترسی سفارشی برای مدیریت کاربران ایجاد گردد. این سیستم باید به صورت Role-Based طراحی شود، در سیستم مذکور باید بتوان مجوزهای کاربران برای دسترسی به یک بخش خاص از نرم افزار و انجام یک عمل را تعیین نمود ،/

مرحله اول : طراحی سیستم و جداول مورد نیاز در دیتابیس

لطفا" نظرات خود را به طور دقیق و با ذکر جزئیات بیان نمایید ،

پیشاپیش از شرکت شما در این بحث سپاسگزارم ،/

پ.ن : مطالبی که از سوی بنده مطرح میشود ، جهت به چالش کشیدن بحث میباشد و بعضا" ممکن است ساده یا با جواب مشخص و معلوم به نظر بیایند ، این بدان خاطر است که قصد بر این است تا این گفتگوها برای افرادی با سطح علمی پایین تر نیز مفید واقع شود و ممکن است این مطالب در ذهن آنها نیز مطرح گردد ، همچنین جهت این است که تمام جوانب نظر شخص شرکت کننده در گفتگو مورد بررسی قرار گیرد،

---

به نام ایزد مننان

تکنیک های زیادی برای تعریف سطح دسترسی وجود دارد بنده در نرم افزارهایی که مینویسم از این تکنیک استفاده میکنم و الحمدلله تا الان هیچ مشکلی پیش نیامده است.

برای این کار دو Table نیاز است:
1- کاربران(شامل 3 فیلد id - Username - Password )
2- سطح دسترس ها (تعداد فیلدها بستگی به تعداد ایتم منوها و به عبارتی بستگی به سطح دسترسی کاربران دارد)
توضیحات دیگر :
اول از همه باید تعداد آیتم های نرم افزار رو تعیین و مشخص کرد : مثلا اگر نرمافزار دارای 5 فرم ورود اطلاعات و 10 فرم گزارش باشد میبایست 5 فیلد برایورود و 10 فیلد برای گزارش در Table سطح دسترسی ایجاد کرد.
علاوه بر آن دکمه های جدید - ذخیره - ویرایش - حذف و غیره را هم اضافه کرد تا سطح دسترسی کاربران برای این دکمه ها نیز هنگام تعریف کاربران ، مشخص کرد.

نقل قول:

---

نوشته شده توسط reza1357

برای این کار دو Table نیاز است:
1- کاربران(شامل 3 فیلد id - Username - Password )
2- سطح دسترس ها (تعداد فیلدها بستگی به تعداد ایتم منوها و به عبارتی بستگی به سطح دسترسی کاربران دارد)

---

بهتره به جاي منو ها و ... در جدول دسترسي ها، نوع كاربران(مثلا مدير، كاربر، مشتري و ...) و انواع دسترسي به هر جدول ديتابيس(مثلا مشخص مي‌كنيم كاربران گروه مدير به چه جداولي از ديتابيس چه نوع دسترسي داشته باشند دسترسي‌هايي مثل Insert,Delete,Select و ...)

و در برنامه قبل از هر عمليات دسترسي گروه كاربر چك شود و اگه دسترسي نداشت پيغام ميده

اگر هم يه كاربر نخاله اي پيدا شد كه Desource كرد و خواست محدوديت رو برداره نمي تونه كاري كنه چون حداكثر از داخل برنامه‌اش چك كردن دسترسي (فعال كردن دكمه‌ها يا منوها) و پيغام رو مي‌تونه برداره ولي باز هم با اين نام كاربريش نمي‌تونه كاري غير از دسترسي از پيش تعيين شده اش انجام بده

با سلام
با توجه به سناریوی تعریف شده توسط دوست خوبم، آقای مداح، پلتفرم تعریف شده، ویندوز می باشد، پس شخصا پیشنهاد میکنم از حداکثر قابلیتهای امنیتی که ویندوز به ما ارائه میدهد استفاده کنیم.
همچنین در راه حلی که اینجانب پیشنهاد میکنم، سیستم امنیتی مورد نظر، تلفیقی از امکانات ویندوز و امکاناتی است که در نرم افزار گنجانده می شود.
ابتدا نیازهای این سیستم بایستی فراهم شود، این نیازها شامل این موارد است :
1. تمام سیستمها به Domain وصل شده باشند.
2. تمام کلاینتها در Active Directory دارای Account با سطح دسترسی مشخص باشند.
3. در نرم افزار مورد نظر، Roleهای استاندارد تعریف شده باشند، مثلا Roleهایی مثل :
الف) Read
ب) Add,Update,Delete
ج) Approve
د) Full Access
4. در نرم افزار مورد نظر، بتوان گروه هایی را تعریف کرد و کاربران Active Directory را به آن اضافه کرد.
5. در نرم افزار مورد نظر، هر آیتم (یا هر فرم یا هر جدول یا هرچیزی که میخواهیم در نرم افزار، به آن سطح دسترسی اعمال کنیم) بایستی دارای بخشی به نام Permisson List باشد، حال در این لیست، گروه هایی که حق دسترسی به آیتم مورد نظر را دارند Add میکنیم و سپس Role مربوطه را به آن گروه اختصاص میدهیم. مثلا گروهی به نام "روابط عمومی" میسازیم و سپس کاربران مورد نظر را از Active Directory به آن اضافه میکنیم، حال در آیتمی به نام اخبار، در بخش Permisson List آن، این گروه را اضافه میکنیم و دسترسی Read به آن میدهیم، اکنون گروه روابط عمومی به بخش اخبار، دسترسی Read دارد.

http://i39.tinypic.com/313oqgx.jpg

تشریح لایه های این سیستم امنیتی بدین صورت است، وقتی کاربری درخواست دسترسی به آیتمی را میدهد، در مرحله ی اول، اعتبار او در Active Directory مورد بررسی قرار میگیرد (که در زمان Log in قرار گرفته است)، سپس در مرحله ی دوم عضویت کاربر در گروهها مورد بررسی قرار میگیرد، سپس در مرحله ی سوم لیست گروههایی که به آیتم مورد نظر دسترسی دارند از بخش Permisson List آیتم مورد نظر مورد بررسی قرار میگیرد و در صورتی که گروههای مجاز بازیابی شده در لیست گروههایی که در مرحله ی دوم بازیابی شده بودند وجود داشت، مطابق با بالاترین سطح دسترسی تنظیم شده میتواند به آیتم مورد نظر دسترسی داشته باشد.
نکته 1 : ذکر واژه ی گروهها به جای واژه ی گروه برای یک کاربر به خاطر این است که یک کاربر در حالت عادی میتواند عضو چند گروه باشد و در مورد آیتم مورد نظر، بالاترین سطح دسترسی تنظیم شده،در حالت عادی سطوح دسترسی پایین تر را Override خواهد کرد.
نکته 2 : هرچند که این روند، سطح امنیتی مناسبی را فراهم خواهد نمود، اما میتوان سطوح امنیتی را بیشتر کرد، یا حتی سطوح امنیتی به صورت سلسله مراتبی ایجاد نمود.

از شرکت تمامی دوستان در بحث سپاسگزارم،/
حال به بررسی پیشنهادهای ارائه ی شده از جانب دوستان می پردازیم،

نقل قول:

---

برای دسترسی به هر بخش در دیتابیس ، در جدول اعضاء ، یک فیلد از نوع bit درنظر میگیریم.
و مقادیر آنها را بصورت زیر پر میکنیم :
به ازای نداشتن دسترسی : 0
به ازای دسترسی کامل : 1

در برنامه ، برای کاربران یک کلاس در نظر گرفته و برای هر قسمت یک متغیر static از نوع bool تعریف میکنیم.
مقادیر این متغیر ها را با توجه به مقادیر متناظرشون در دیتابیس هنگام ورود کاربر به سیستم پر مکنیم.

در آخر در رویداد Load هر فرم ، سطح دسترسی کاربر مذکور را بررسی میکنیم و فعال یا غیر فعال بودن کنترل ها (مثل دکمه ها) را تنظیم میکنیم

---

این ایده توصیه نمی گردد، چون:
1) پیاده سازی Role-Based Security به شیوه صحیح در آن امکان پذیر نیست،
2) تعداد فیلدهای دیتابیس بسیار زیاد شده و جدول از فرم نرمال خارج می گردد،
3) برای افزودن یک Permission جدید، باید ساختار جدول تغییر کرده و یک فیلد به آن اضافه گردد،
4) این ایده خلاف اصول طراحی دیتابیس است، زیرا مشخصات کاربر و مجوزهای او باید در جداولی مجزا نگه داری شوند و ذخیره ی آن ها در یک جدول باعث کاهش Performance و پیچیده شدن برخی کوئری ها و Constraint ها می گردد،
5)امکان اضافه نمودن لایه های امنیتی دیگر به این سیستم به شیوه صحیح وجود ندارد،
6)با توجه به نکنه ی 4، نفوذگر با دسترسی به جدول اعضاء، می تواند مجوزهای آنان را نیز مشاهده و تغییر دهد،
7)....

نقل قول:

---

خوب بعد از مشخص شدن Actor هاي سيستم همون طور كه خودتون اشاره كردين بايد براي هر User توسط مدير سيستم Role تعريف بشه تا بتونه در قسمتهاي مختلف سيستم گردش كنه.
فيلدهاي منطقي كه بايد در جدول پايگاه داده ساخته بشه مي تونه شامل درج، حذف، ويرايش و مشاهده باشه كه خودشون عمليات هاي مجزا هستن. همچنين به ازاي هر Actor سيستم بايد به توان عمليات اون سيستم كلاس نوشته بشه:
کد:
Classes: Actor ^ Action

---

چرا باید این تعداد زیاد کلاس در برنامه ایجاد گردد؟
برای تفهیم بهتر موضوع بهتر است که دیاگرام جداول دیتابیس و نیز Class Diagram سیستم را در اینجا قرار دهید،

نقل قول:

---

2- سطح دسترس ها (تعداد فیلدها بستگی به تعداد ایتم منوها و به عبارتی بستگی به سطح دسترسی کاربران دارد)

---

این ایده نیز مورد تایید نیست، زیرا(دلایل مشابه به طرح جناب jaza_sa):
1) پیاده سازی Role-Based Security در آن به شیوه صحیح امکان پذیر نیست،
2) تعداد فیلدهای دیتابیس بسیار زیاد شده و جدول از فرم نرمال خارج می گردد،
3) برای افزودن یک Permission جدید، باید ساختار جدول تغییر کرده و یک فیلد به آن اضافه گردد،
4) این ایده خلاف اصول طراحی دیتابیس است، زیرا ذخیره ی این تعداد زیاد فیلد باعث کاهش Performance و پیچیده شدن برخی کوئری ها و Constraint ها می گردد،
5)امکان اضافه نمودن لایه های امنیتی دیگر به این سیستم به شیوه صحیح وجود ندارد،
دهد،
6)....

نقل قول:

---

بهتره به جاي منو ها و ... در جدول دسترسي ها، نوع كاربران(مثلا مدير، كاربر، مشتري و ...) و انواع دسترسي به هر جدول ديتابيس(مثلا مشخص مي‌كنيم كاربران گروه مدير به چه جداولي از ديتابيس چه نوع دسترسي داشته باشند دسترسي‌هايي مثل Insert,Delete,Select و ...)

---

بله، این ایده تا حدودی به هدف ما نزدیک تر است، Role ها، کاربران(User) ها، گروه Roleها(RoleGroups)، اجزای سیستم(Objects)، عملیات های ممکن(Operations/Actions)، عملیات های قابل انجام بر روی هر یک از اجزای سیستم و مجوزهای کاربران و Role ها و ... باید همگی در جداول مجزا نگه داری شده و با یکدیگر ارتباط داشته باشند و به هیچ عنوان:
1)نباید مجوزهای اعضا و مشخصات آنان در یک جدول نگه داری شوند،
2)نباید برای هر یک از مجوزها/بخش های سیستم یک فیلد مجزا ایجاد گردد،
3)...

@hdv212
حامد جان، ایده ی بسیار جالبیست،
زیرا در این طرح، سیستم ما از امکانات Active-Directory بهره می گیرد و مسلما" امنیت بالاتری را به دست می دهد و از انعطاف پذیری مناسبی برخوردار است و نیز امکان افزودن لایه های امنیتی دیگر در سطح Application وجود دارد، چند نکته:
1)برای Extend کردن Schema ی Active Directory از چه روشی استفاده می کنید؟
2)برای اضافه نمودن سطوح/لایه های امنیتی چگونه عمل می کنید؟
3)...


مجددا" از شرکت تمامی دوستان در این بحث سپاسگزارم،/

با سلام
خواهش میکنم علیرضا جان

1. در مورد Extent کردن اسکیماها در AD، میتونی بیشتر در این مورد توضیح بدی، چون من زیاد از مفاهیم شبکه سر در نمیارم، ولی شما از طریق نرم افزار خودتون کاملا میتونید با AD تعامل داشته باشید.

2. هرچند که سطوح امنیتی که در پست قبلی ذکر کردم، امنیت را تا حد قابل قبولی ارائه میدهد، اما میتونید سطوح امنیتی بیشتری به این سیستم اضافه کنید، مثلا سطوح امنیتی به صورت سلسله مراتبی، بدین صورت که در پیکربندی اصلی نرم افزار گروهها تعریف میشوند و سطوح دسترسی مشخصی در حیطه ی کل نرم افزار به آن گروهها داده میشود، سپس در آیتمهای زیر مجموعه، تعیین میکنیم که آیا سطح دسترسی از نرم افزار اصلی Inherit شود یا به صورت جداگانه مشخص شود. در این صورت یک لایه ی امنیتی دیگر به نام سیاسیتهای تعیین دسترسی در حیطه ی کل برنامه اضافه خواهد شد که میتواند امنیت بیشتری را برای ما فراهم نماید.

امیدوارم به درستی سوال شما رو متوجه و پاسخ درست را ارائه داده باشم.
با تشکر

نقل قول:

---

1. در مورد Extent کردن اسکیماها در AD، میتونی بیشتر در این مورد توضیح بدی، چون من زیاد از مفاهیم شبکه سر در نمیارم، ولی شما از طریق نرم افزار خودتون کاملا میتونید با AD تعامل داشته باشید.

---

در خصوص Extend کردن AD مطلب زیر مفید است:
Microsoft - How To Extend Schema

و همچنین مقاله زیر:
InformIT - Extending the Active Directory Schema To Track Custom Data
http://www.informit.com/content/imag...inks/fig01.gif

نقل قول:

---

1)برای Extend کردن Schema ی Active Directory از چه روشی استفاده می کنید؟

---

این کار بیشتر به عهده ی مدیر شبکه می باشد و نیازی نیست نرم افزار با AD تعامل دو طرفه داشته باشد، پس از اعمال تغییرات در اکتیو دایرکتوری، نرم افزار با Query مجدد به AD میتواند اطلاعات جدید را دریافت کند.

ن از وابسته شدن نرم افزارهای خودم با سیستم های دیگر اصلا خوشم نمی آید. کاری که همیشه می کنم

1: نرم افزار من چه کاری قرار هست انجام بدهد
من از این کارها به فعالیت (Activity) نام می برم
بعد خوب یک سری باید گروه تعریف کنم
بعدش باید این فعالیتها را به گروه ها ربط بدم
بعدش کاربر ها را به گروه ها
داخل برنامه ام یک آرایه دارم به تعداد کل فعالیتها وقتی کاربر داخل برنامه می شود من این آرایه مقدار دهی می کنم ، در هر فرم مشخص می کنم که کابر اگر مجوز فعالیت خاص را داشته باشد به این فرم دسترسی دارد.
یک سری کار هم باید انجام بدهم موقع داخل شدن کاربر مانند کنترل رمز ورود ، آیا کاربر فعال هست و ...
یک کلاس به اسم UserManager دارم که این کارها را در آن انجام می دهم
خواستید بعد در مورد نحوه اجرا هم با هم صحبت می کنیم

ضمن تشكر از مطالب ارزشمندهمه دوستان براي آگاهي خودم مي پرسم كه :

نقل قول:

---

زیرا در این طرح، سیستم ما از امکانات Active-Directory بهره می گیرد و مسلما" امنیت بالاتری را به دست می دهد و از انعطاف پذیری مناسبی برخوردار است و نیز امکان افزودن لایه های امنیتی دیگر در سطح Application وجود دارد

---

يك نقطه قوت است يا يك ضعف است كه ما برنامه خودمان را وابسته به Domain , Active-Directory كنيم ؟

نقل قول:

---

يك نقطه قوت است يا يك ضعف است كه ما برنامه خودمان را وابسته به Domain , Active-Directory كنيم ؟

---

دوست عزیز، اگر قرار است که برنامه شما در یک Domain Environment استفاده شود، مسلما" می توانید از ویژگی های آن و امنیت بالای آن بهره گیری نمایید، اما در این حالت برنامه شما مبتنی بر Domain بوده و به آن وابسته خواهد بود(در صورت عدم انعطاف پذیری سیستم)، این مسئله دقیقا" بستگی به سناریوی شما دارد،/

نقل قول:

---

نوشته شده توسط linux

یک کلاس به اسم UserManager دارم که این کارها را در آن انجام می دهم
خواستید بعد در مورد نحوه اجرا هم با هم صحبت می کنیم

---

اگر در مورد نحوه اجرا هم توضیح بدید، بسیار عالی میشه.
یک سوال:
جدول u.computers چه اطلاعاتی رو نگهداری می‌کنه؟ در حقیقت، کاربرد این جدول چی هست؟؟

نقل قول:

---

نوشته شده توسط naeeme

اگر در مورد نحوه اجرا هم توضیح بدید، بسیار عالی میشه.
یک سوال:
جدول u.computers چه اطلاعاتی رو نگهداری می‌کنه؟ در حقیقت، کاربرد این جدول چی هست؟؟

---

با یک مثال توضیح خواهم داد.
جدول کامپیوترها برای نگهداری اطلاعات کامپیوترهایی که از این نرم افزار استفاده می کنند طراحی شده است.هدف این هست که در صورت لزوم کامپیوتری هم که کاربر اجازه ورود به سیستم داره محدود بشود یا اینکه مشخص بشود کاربر از کدام رایانه استفاده کرده.
در یک جا یک کاربر با استفاده از نام کاربر و پسورد کاربر دیگر اقدام به تغییر اطلاعات و درج نادرست اطلاعات جدید کرده بود که همه به گردن کاربر مذکور می افتاد ، و کاربر مذکور هم هیچی به گردن نمی گرفت و نمی توانست ثابت کند ، با این کار مشخص می شود کدام کاربر از کدام کامپیوتر لاگین کرده ، و در یک شبکه شما می توانید کامپیوترها را برای استفاده از برنامه خودتان محدود کنید.

نقل قول:

---

از وابسته شدن نرم افزارهای خودم با سیستم های دیگر اصلا خوشم نمی آید.

---

بله، من هم از شیوه ی مشابه شما در سیستمهای کوچکتر استفاده میکنم، به عبارت دیگه، سامانه ای رو که عرض کردم در سیستمهای کوچک اصلا کاربرد ندارد. اما در سیستمهای اتوماسیون اداری با چندین یا چندصد کاربر که در سطح دامین کار میکنند و امنیت و در عین حال عدم پیچیدگی نرم افزار براشون مهمه، یکپارچگی نرم افزار شما با اکتیو دایرکتوری ویندوز میتونه قابلیت بسیار خوبی برای نرم افزار شما باشه. فرض کنید کاربری به تازگی استخدام شده و ادمین شبکه برای او یک حساب و کلیه اطلاعات مورد نیاز (از جمله اطلاعاتی از قبیل ایمیل داخل سازمان) رو در اکتیو دایرکتوری وارد کرده، حالا زمانی که کاربر وارد کامپیوترش میشه دیگه نیازی نیست برای ورود به نرم افزار هم یک نام کاربری و پسورد دیگه ای رو وارد کنه، از طرف دیگر، اگر نیاز به ذخیره ی اطلاعات بیشتری از کاربر باشه (مثل همون ایمیل و ...)، من شخصا پیشنهاد میکنم لقمه رو دور سرمون نپیچونیم!
همچنین از امکانات دیگه ای که حسابهای اکتیو دایرکتوری دارا می باشند هم میتونید استفاده کنید، مثلا کاربرانی که در شبکه ای خارج از دامین سازمان هستند به صورت Cross-Domain میتونن وارد نرم افزار مورد نظر بشن و امکانات دیگه، یا اگر کاربری از سازمان رفت و اطلاعات اون از AD پاک شد، نرم افزار هم به تبع اون دیگه حق دسترسی به کاربر مورد نظر نخواهد داد و ....
ایده ی شما بسیار عالیه حتی برای اتوماسیون های بزرگ، اما با توجه به شرایط و ضوابط و موقعیت و .... استفاده از امکانات AD هم میتونه مفید باشه!

سلام،

من تازه کار هستم و کار ویندوز انجام ندادم مگه یکی دوتا پروژه کوچولو دانشگاهی!

روشم اینه که سه جدول در نظر می گیرم:

1)جدول کاربران (شامل فیلدهای:id، نام کاربری، کلمه عبور )

2)جدول مجوزهای موجود در سیستم (id،نام مجوز) در این جدول مجوزهای لازم رو بصورت رکورد در این جدول وارد میکنم و فیلد آیدی رو بصورتidentity در مییارم -مجوزهای مثل اضافه،حذف،ویرایش،نمایش فلان جدول -

3)جدول دادن مجوز به کاربر(آیدی، آیدی از جدول2، آیدی جدول 1) -یعنی میگم فلان کاربر با شماره کاربری (همون ایدی جدول1) به فلان مجوز با ایدی فلان از جدول2 دسترسی داره.

(فیلد آیدی در هر سه جدول از نوعbigint و identity می کنم)
بعد برای چک هم یک کلاس می نویسم و توابع چک اینکه کاربر مجوز داره رو اونجا می نویسم و بعد در فرم لود این تابع رو فراخوانی میکنم اگه مجوز نداشت مثلا دسترسیشو به فلان فرم منع میکنم یا ففلان دکمه رو براش نامرئی میکنم یا غیرفعال ....


خوشحال میشم در مورد روشم نظر بدید.
و اینکه میگم اگه بخوام گروهی مجوز بدم چطوریه؟خب ممکنه مثلا یک کاربری عضو یک گروه باشه و مدیر بخواد بنابه دلیلی دسترسی این کاربر رو به یکی از اون مجوزها که گروهی که کاربره درش قرار داره رو منع کنه چطوری میشه؟!


ازتون بابت تدارک سناریوها تشکر میکنم:لبخندساده::تشویق:

معمولا در نرم افزارهای اتوماسیون چند دبیرخانه با کاربران و گروههای مخصوص به خود وجود دارد. در این صورت همیشه باید برای کاربر یا مجوز فیلد id دبیرخانه نیز در نظر گرفت.

نقل قول:

---

نوشته شده توسط h.alizadeh

سلام،

و اینکه میگم اگه بخوام گروهی مجوز بدم چطوریه؟خب ممکنه مثلا یک کاربری عضو یک گروه باشه و مدیر بخواد بنابه دلیلی دسترسی این کاربر رو به یکی از اون مجوزها که گروهی که کاربره درش قرار داره رو منع کنه چطوری میشه؟!


ازتون بابت تدارک سناریوها تشکر میکنم:لبخندساده::تشویق:

---

برای این کار باید اولویت هات رو تو سیستم مشخص کنی، یک قانون کلی داریم: <مجوز های شخص بر گروه ارجحیت داره> با این قانون مشکلت حل میشه، البته برای گروه هایت هم باید یک جدول جدا بگذاری.

استفاده از امکانات خود پلتفورم دات نت بی شک بهترین و مورد اعتمادترین (مورد اعتمادتر از راهکارهای ما) گزینه ست.
برای تشخیص هویت (Authentication) استفاده از Role-based Security دات نت فریم ورک که به دو صورت توصیفی و دستوری انجام میشه.
و برای اعطای مجوز (Authorization) استفاده از AzMan.

لطفا در مورد استفاده از آنها در دات نت توضیح دهید:متفکر:

از pattern های توصیه شده توسط خود مایکروسافت استفاده کنین. توضیح و تشریح این روش ها تو این پست ها امکان پذیر نیست.

http://msdn.microsoft.com/en-us/library/aa302415.aspx

آیا در مورد (Record-level access) روشی رو دارید

دوستان مطالبتون جالب بود .
ای کاش یک نمونه مثال در مورد سطح دسترسی هم می دادید.

نقل قول:

---

نوشته شده توسط davoodrm666_666

آیا در مورد (Record-level access) روشی رو دارید

---

من این کار رو به این صورت انجام دادم:
یه جدول دارم به این شکل:
ID bigint
UserID bigint
TableID binary(customer security = censored)-- X Checksum of table.Y

FirstRow binary(32) -- binary is because of tables that have more than 1 PK
LastRow binary(32) nullable -- nullable is for single-row access levels

State(tinyint) 0=unspecified = unvisible 1=readonly 2 = Read+WriteWithModeratorPermission 3= unvisible 4 = ReadWrite

اون دو ستونی که underline دارن رو من طور دیگه نگهداری میکنم binary(64) و در زمان اجرا deserialize میکنم.

ببین چجوری حرص آدم رو در میارید آخه ! لول! به این سادگی ها نیست که طرف بیاد اکتیو دایرکتوری تنظیم کنه و بیاد صفر و یک بگیره و این حرفها...نرم افزاه حرفه ایه . بچه بازی که نیست. اگه این همکاران سیستم و شرکتهایی که اسمشون رو به عنوان "خدا!" داخل این فروم به وفور دیده ام هم دارند اینجوری برنامه تحویل میدهند که it is Scary . البته شدنش رو که میشه! ولی خب میشه همین کیفیت ایران خودرو که میبینیم! لول.

ما خودمون چندین کیلو خط کد SQL به اسکریپت های موجودمون اضافه کردیم تا این کار رو بصورت کاملا حرفه ای و بی نقص به مشتری درخواست کننده تحویل بدهیم. آنها یک دیتابیس Shared استفاده میکردند ولی Schema متفاوتی داشتند . حالا بیا و درستش کن.! در مقیاس حرفه ای اگر چنین سوالی رو بخواهید حل کنید باید معماری Multi Tenant رو مطالعه و گوگل کنید. والله "گول گاز نمیگیرد . گوگل دوست شماست.

http://en.wikipedia.org/wiki/Multitenancy

http://msdn.microsoft.com/en-us/library/aa479086.aspx

ادامه پست قبل:

میتونید Multi Tenant رو تا زمانی که واقعا مشتری هاتون بهش احتیاج داشته باشند به تاخیر بندازید چون واقعا کار چندان ساده ای نیست.
اما از نظر من اصلا خوب نیست که یک "معماری" و نه "کد" تا حد زیادی به زبان و سیستم عامل و ... وابسته باشه. مثلا وقتی در راه حلتون دارید Active Directory رو وارد میکنید یعنی کاملا محدود به ویندوز شد و خلاص. در حالیکه برای مثال نرم افزار من رو خیلی مشتری ها با back-end ویندوز اجرا میکنند برخی با HP-UX ..یکیشون با لینوکس و برخی هم با OpenVms ... کارهایی مثل بررسی امنیت و غیره باید کاملا زیربنایی باشه در معماری . و نه وابسته به امکانات زبان خاص. وگرنه به عنوان یک مثال کاملا عینی تصور کنید این 1.2 الی 1.6 میلیون خط کد که فقط برای تیم پاتولوژی بود رو تازه اگر میخواستیم بشینیم یک راه حل جدید بخاطر زبان جدید هم واسش درست کنیم چه جهنمی میشد.

در نرم افزار یک چیز شناخته شده ای داریم به نام RBAC - تلفظ کنید آر بَک - حالا این رو میتونید بصورت مستقل از زبان پیاده سازی کنید یا اینکه خودتون رو محدود به یک زبان کنید .

راه حل کلی: http://en.wikipedia.org/wiki/Role-Based_Access_Control

راه حل دات نتی: http://www.codeguru.com/Csharp/Cshar...cle.php/c7415/

http://upload.wikimedia.org/wikipedia/en/c/c3/RBAC.jpg

نقل قول:

---

نوشته شده توسط linux

ن از وابسته شدن نرم افزارهای خودم با سیستم های دیگر اصلا خوشم نمی آید. کاری که همیشه می کنم

1: نرم افزار من چه کاری قرار هست انجام بدهد
من از این کارها به فعالیت (Activity) نام می برم
بعد خوب یک سری باید گروه تعریف کنم
بعدش باید این فعالیتها را به گروه ها ربط بدم
بعدش کاربر ها را به گروه ها
داخل برنامه ام یک آرایه دارم به تعداد کل فعالیتها وقتی کاربر داخل برنامه می شود من این آرایه مقدار دهی می کنم ، در هر فرم مشخص می کنم که کابر اگر مجوز فعالیت خاص را داشته باشد به این فرم دسترسی دارد.
یک سری کار هم باید انجام بدهم موقع داخل شدن کاربر مانند کنترل رمز ورود ، آیا کاربر فعال هست و ...
یک کلاس به اسم UserManager دارم که این کارها را در آن انجام می دهم
خواستید بعد در مورد نحوه اجرا هم با هم صحبت می کنیم

---

اگر امکان دارد در مورد نحوه اجرا هم توضیح دهید و کلاس UserManager رو هم شرح دهید
با تشکر فراوان

با سلام خدمت دوستان
بنده(و گروه مان) چنین سیستمی را پیاده سازی کرده ایم
در کل تمامی سیستم ها بایستی در یک قالب مشخصی قابل اجرا کردن باشند که مابه آن کارتابل می گوییم ، کارتابل درحقیقت یک برنامه ای است که وظیفه گردش کار و مشاهده و برخی از این موارد را برعهده دارد ، اگر بخواهید یک سیستم کاملا امن داشته باشید بهتر است یا از وب سرویس استفاده کنید و یا کاملا وب بیس برنامه نویسی کرده باشد در هر حال سعی کنید حداقل بخش کنترل کلمه عبور و رمز وب سرویس باشد
حال می روم سر اصل مطلب
اصل مطلب یعنی چگونگی کنترل و اعطا دسترسی سیستم های اتوماسیون به کاربران و تعریف نقش و فعالیت برای سیستم ها و دسترسی آن به کاربران است
اگر یک سیستم را به بخشهای زیر تقسیم کنیم راحت تر می توانیم بحث کنیم
1-کنترل ورودی(login) با کلمه کاربری و رمزورود
2-بخش بارگذاری سطح دسترسی فرد وارد شده و اعطا و سلب دسترسی
3-کارتابل و لینکهای ورود به سیستم ها بعلاوه بایگانی و کارهای ارسال شده
4-سیستم های کاربردی که به شکل خاصی و در اسمبلی های مختلف قابل افزودن به سیستم یکپارچه بالا می باشند
در این بین اگر از orm مشترکی استفاده شود بهینه تر می باشد
هنگامی که فردی وارد سیستم می شود بعد از احراز هویت یک کلید یکتا ایجاد شده و تا زمانی که ارتباط فرد با سیستم قطع نشده است این کلید در حافظه سرور و کلاینت باقی می ماند (این کلید می تواند یک guid باشد)
و در هر بار که کاربر در کارتابل فعالیتی انجام بدهد احراز هویت با این کلید است و تمامی دسترسی های فرد نیز با وارد شدن به سیستم بارگذاری شده است و لذا امنیت تاحد زیادی برقرار استپ
حال می رویم سراغ نحوه کار سیستم دسترسی
سیستم دسترسی دو بخش داده 1-اعطا دسترسی 2-بارگذاری و اعمال دسترسی به کارتابل و محیط کاربردی فرد
سیستم ورود -دسترسی اعطا و سلب با هم در یک یا چند جدول مشتر ک می باشند پ
ابتدا بایستی جدول های زیر برای سیستم اعطا و اعمال دسترسی در نظر گرفته شود
1-جدول person که مشخصات افراد در آن قرار دارد
2-جدول Users که مشخصات کاربری افراد در آن قرار دارد و با یک کلید خارجی با person در ارتباط استپ
3-جدول task,role,UserAccess
بقیه توضیحات بماند برای بعد لطفا نظر داده و سوال کنید تا بیشتر توضیح بدهم

سلام لطفا در مورد حدول access بیشتر توضیح دهید