ניהול הרשאות, משתמשים, קבוצות הרשאה וחיות אחרות
בפוסט הקודם הבטחתי להתחיל לכתוב קצת על Governance - אז הנה הנושא הראשון והחשוב ביותר לדעתי - ניהול הרשאות.
נושא הקצאת הרשאות למשתמשים ולפריטי מידע הוא אחד המרכזיים ביותר בכל מערכת, בוודאי ב- SharePoint 2007, שעשה קפיצת דרך גדולה מאז גירסת 2003. הבעיה היא שמודל ההרשאות קצת מורכב ולא תמיד ברור איך בדיוק עושים מה ואיפה.
שתי בעיות מרכזיות אחראיות ל"ערפל הקרב" הזה לדעתי, ואני מקווה לתת להן מענה בסיסי בפוסט הזה:
1. "קבוצות" SharePoint - ארכיטקטי המוצר הוסיפו ישות בשם "Group" המהווה קבוצת הרשאות פנימית של SharePoint. הבעיה שלא מעט מתבלבלים בינן לבין קבוצות ההרשאה הרגילות של Active Directory, או שכלל לא מבינים את הצורך בהן.
2. דפי הניהול - בכדי לנהל את מערך ההרשאות, יש צורך להשתמש לפחות ב- 4 דפי ניהול, בכל אחד פעולות משלו, ובחלקם ישנן פעולות זהות, מה שמגדיל את הבלבול - איפה עושים מה?
הנחת העבודה שלי בפוסט היא שאתם מכירים ברמה סבירה מה זה Active Directory - אם לא כל-כך -
תקראו ב- Wikipedia, זה מסביר הכל. אגב, המודל תקף כמובן גם במקרה של זיהוי מבוסס טפסים (Forms Authentication), אלא שבמקום AD יש לנו את ה- asp.net DB או כל מסד משתמשים אחר.
"גליון הרשאות" - הבנת מודל ההרשאות ב- MOSS 2007
לפני שנתחיל, נסתכל רגע על הסכימה הבאה, שמתארת את מודל ההרשאות ושיוכן למשתמשים\קבוצות במערכת. שימו לב שמתחת לכל "ישות" הוספתי את שם דף הניהול הרלוונטי (יש להוסיף כמובן את כתובת האתר לפני ה- /Layouts_. במקרה של דף admin_ יש להוסיף את כתובת אתר הניהול המרכזי). מייד תקבלו הסבר מושגים + הסבר תהליכים לתרשים הזה:
הסבר מושגים
הרשאות - זה ה"סל" של כל סוגי\פרטי ההרשאה האפשריים, ברזולוציה הגבוהה ביותר. לא ניתן להוסיף הרשאות מעבר לקיים (למשל אם תרצו לתת למשתמש הרשאות להוספת wp מסוג עורך תוכן בלבד וכדומה). לשם נוחות, מחולקות ההרשאות ל- 3 קבוצות תצוגה: רשימה, אתר ואישיות - אבל אין לכך משמעות פונקציונלית. המקבילה של זה ב-AD הן כמובן ההרשאות read, write, execute וכו'.
חשוב לזכור, ותראו את זה בהמשך כשתקבצו רמות הרשאה להרשאות וכו', כי ישנן רמות הרשאה התלויות זו בזו: אם בחרתם ברמת ההרשאה "הוספת פריטים" אוטומטית ייבחר גם "הצגת פריטים" וכן הלאה. לכן אל תסתמכו על הרשימה כדי לקבוע שניתן לתת הרשאות אך ורק לפעולות אלו ואחרות, אלא תנסו בפועל לבחור ותראו מה נבחר אוטומטית ביחד עם בחירתכם.
רמות הרשאה - קבוצות\קטגוריות של הרשאות, או בלשון אחרת - Roles. כאן כבר ניתן להוסיף Roles משלנו, שיורכבו למעשה מסט של הרשאות כאלו ואחרות, על-פי החלטתנו. המקבילה של זה ב-AD היא למשל Full Control, שלמעשה מסמנת אוטומטית את כל רמות הרשאה הקיימות.
אפשרות נוחה מאוד היא "העתק רמת הרשאה", שמאפשרת "להתלבש" על רמת הרשאה קיימת וליצור ממנה חדשה עם השינויים הרלוונטיים, במקום להתחיל מאפס.
קבוצות SharePoint - הקצאה של רמת הרשאה ספציפית למשתמשים\קבוצות מה- AD. אם ב-AD הקבוצות מכילות רק משתמשים\קבוצות אחרות, הרי שכאן הקבוצות מכילות גם הרשאות כחלק בלתי-נפרד מהגדרת הקבוצה.
בהתאם לכך, ישות לוגית זו מאפשרת שתי פעולות עיקריות:
- קיבוץ של משתמשים\קבוצות מה-AD מצד אחד
- הקצאת הרשאה (אחת בלבד) לקבוצה מצד שני.
הסבר תהליכים
בהנחה והגדרות ברירת המחדל של MOSS לא מספקות אותכם, או שאתם רוצים לחקור אותן, סדר הפעולות הוא כזה (המספור עפ"י התרשים):
- באתר הניהול המרכזי החליטו אילו הרשאות יהיו בכלל חשופות בכל אוספי האתרים (admin/vsmask.aspx_).
- לאחר מכן באוסף האתרים הרלוונטי קבצו הרשאות לרמות הרשאה מתאימות, עפ"י הצורך.
- אופציה א': הקצו רמות הרשאה ישירות למשתמשים\קבוצות מה- AD
- אופציה ב': הקצו רמות הרשאה לקבוצות SharePoint ובמקביל -
- אופציה ב' - המשך: שייכו משתמשים\קבוצות מה- AD לאותן קבוצות SharePoint
מתי להשתמש בקבוצות SharePoint?
שאלה מצויינת - למרות שהקבוצות האלו מוטבעות בפורטל, ואוטומטית מקבלים אוסף של קבוצות כאלו, מומלץ לחשוב טוב לפני שמשתמשים בהן, בשל הכפילות והבלבול שעלולים להיווצר.
אז קודם כל חשוב להבין את המטרה של הישות הזו - בגדול המטרה היא "לעקוף" מצבים בהם אין קבוצות מתאימות ב- AD שיקבצו אוסף של משתמשים להם רוצים לתת הרשאה מסויימת בפורטל. לדוגמה: אם יש לי הרבה משתמשים להם אני רוצה לאפשר יכולות ניהול מלאות באתר, אני יכול לבנות קבוצת SharePoint בשם "בעלי אתר" (כן, אני יודע שיש כזו...) ולשייך אליה את המשתמשים הרלוונטיים מה- AD.
היתרון בכך הוא, שניתן לשנות את "אופי" הקבוצה בפעולה אחת, וזה יחול רוחבית - לדוגמה, אם אני רוצה שמנהלי האתר יהפכו למשתתפים בלבד, כל שעליי לעשות הוא לערוך את הקבוצה ולתת לה הרשאת "השתתפות" במקום "ניהול". כנ"ל אם אני רוצה למנוע ממשתמש בודד לנהל את האתר - אני עורך את הקבוצה ומסיר אותו ממנה וזה יחול על כל המקומות בהם לקבוצה זו יש הרשאות.
ככלל אצבע, רק בהתקיים שני התנאים הבאים במצטבר יש מקום להשתמש בקבוצות:
- אין קבוצה מתאימה ב- AD
- קיימות מספר ספריות\רשימות\אובייקטי תוכן להם יש צורך לשייך את אותה קבוצה בדיוק
מתי כדאי להשתמש בקבוצות SP - דוגמה:
אתם מעוניינים לתת לקבוצת משתמשים בארגון יכולת ליצור תצוגות אישיות ברשימות. למשתמשים אלו אין מכנה ארגוני משותף (ולכן לא יטרחו ליצור להם קבוצה ב- AD) וכמות הרשימות האפשריות היא גדולה. כאן קבוצות SP נותנו מענה מצויין - צרו רמת הרשאה בשם "משתתף עם תצוגות אישיות", שייכו אותה לקבוצת SP בשם "משתתפים עם תצוגות אישיות" ובמקביל שייכו לקבוצה הזו את כל המשתמשים המתאימים מה- AD.
מתי לא כדאי להשתמש בקבוצות SP - דוגמה:
אתם יוצרים מספר סקרים בארגון. לכל סקר קהל יעד משלו, להם נדרש לתת הרשאות השתתפות בסקר. אם תשתמשו בקבוצות SP, תצטרכו ליצור מס' קבוצות כמספר הסקרים + תצטרכו לנהל שיוך ידני של משתמשים לקבוצות. אם תשתמשו בקבוצות AD - פעם אחת תשקיעו ביצירת הקבוצות (בד"כ באחריות ה- IT), ומכאן והלאה לכל סקר תשייכו ישירות רמת הרשאה לקבוצת ה- AD המתאימה.
טיפ קטן - הרשאה מוגבלת
לא דיברתי בפוסט על הצד השני של המטבע - איך נותנים הרשאות לאובייקטי תוכן שונים (ספריות, מסמכים וכו'), וכמובן נושא ההורשה או ה"שבירה" של הרשאות בין ישויות.
אבל שימו לב למשהו אחד מעניין ומוזר - במקרה של "שבירת" הרשאות (=מתן הרשאות ייעודיות למשתמשים מסויימים על פריטים מסויימים), אם תלכו לדף ניהול ההרשאות (user.aspx) של אתר האב, תראו פתאום שאותם אנשים נוספו כ"הרשאה מוגבלת". זו הדרך של MOSS להודיע למנהל האתר שיש באתר אנשים בעלי הרשאה חריגה על פריטי תוכן. זה יכול להיות מאוד מטריד כשמדובר באתר עם הרבה "שבירות" - מתקבלת רשימה גדולה מאוד של בעלי הרשאה מוגבלת - אבל זה מה יש, לפחות ככל הידוע לי.
מקורות
מומלץ לעיין במאמר הבא:
http://technet2.microsoft.com/Office/en-us/library/610a48d4-a805-4c47-8801-a8a912b294ea1033.mspx?mfr=true
ובבלוג הבא של Sahil Malic שמדגים חלק ממה שהצגתי:
http://blah.winsmarts.com/2007-4-SharePoint_2007__Fine_grained_permission_control.aspx