CAS Development

مقدمه

امروزه تعدد سامانه‌های نرم‌افزاری مختلف برای کاربران یک مشکل بزرگ ایجاد کرده است. هر کاربر می‌بایست نام‌های کاربری و رمزهای عبور مختلفی را به خاطر بسپارد و از آن‌ها جهت ورود استفاده کند. اکثر سامانه‌های نرم‌افزاری نیز برای سهولت از بانک اطلاعاتی خود جهت مدیریت کاربران استفاده می‌کنند. این امر باعث می‌شود تا اطلاعات کاربران بارها در سامانه‌های مختلف تکرار شود و حتی بعضا به علت تعدد تکرار به صورت اشتباه هم وارد شود.

بسیاری از سازمانها جهت حل این مشکل از سرویس‌هایی بر پایه LDAP استفاده می‌کنند تا هویت کاربران یکپارچه شود و از تعدد نام کاربری و رمز عبور جلوگیری شود. کارکرد این سرویس نیازمند اتصال همه سامانه‌های نرم‌افزاری به پروتکل LDAP جهت احراز هویت هست. اگر چه مشکل تعدد نام کاربری حل می‌شود اما مشکل دیگری ایجاد می‌شود. تصور کنید که یک کاربر روزانه به ۱۰ سامانه نرم‌افزاری مختلف می‌خواهد متصل شود و رمز کاربر نیز پیچیده باشد. کاربر حداقل ۱۰ بار باید نام کاربری و رمز عبور خود را وارد کند تا بتواند از این سامانه‌ها استفاده کند. اگر این مقدار را با تعداد کابران محاسبه کنیم به حجم بسیار بالایی از ورود خواهیم رسید.

جهت سهولت در ورود و خروج کاربران از سامانه‌های مختلف و حل مشکل فوق، از سرویس‌های SSO یا یکبار ورود استفاده می‌شود. این سرویس‌ها پروتکل‌های مختلفی را اصولاً پوشش می‌دهند که شامل CAS, OAuth2, SAML و یا بصورت وب‌سرویس Restful خواهد بود. سامانه‌ها در صورتی که بر روی یک پروتکل مشترک احراز هویت را انجام دهند توسط Ticket صادره از سرویس SSO می‌توانند اعتبار ورود کاربر را بررسی نموده و در صورتی که ticket مربوطه هنوز معتبر باشد امکان و اجازه ورود کاربر را بدون وارد نمودن نام کاربر و رمز عبور بدهند. در هنگام خروج یک کاربر از یک سامانه نیز با استفاده از SLO یا یکبار خروج و اعلام آن به سرویس SSO می‌توان ticket مربوطه را بی‌اعتبار کرد و دسترسی کاربر از همه سامانه‌ها به جهت امنیت قطع خواهد شد.

در ادامه به نحوه چگونگی اتصال و اعتبارسنجی این سرویس می‌پردازیم.

پروتکل CAS

یکی از پروتکل‌هایی که برای تکنولوژی SSO استفاده می‌گردد، CAS نام دارد که مخفف Central Authentication Service هست. این پروتکل توسط شرکت Apereo ابداع شده است و برای زبانهای مختلف برنامه‌نویسی کتابخانه داشته و استفاده از آن سهولت زیادی نسبت به سایر پروتکل‌ها دارد که دلیل آن کتابخانه‌های خوبی هست که در سمت سرویس‌گیرنده فراهم شده است. کتابخانه‌های CAS محدود به زبانهای برنامه‌نویسی نیستند و در وب‌سرورهایی مانند Apache نیز این کتابخانه‌ها وجود دارند که به نام mod_auth_cas شناخته می‌شود و یا حتی در سیستم‌عامل لینوکس برای PAM نیز کتابخانه pam_cas وجود دارد.

برای دریافت این کتابخانه‌ها بسته به نوع زبان می‌توان از مسیر کلی https://github.com/apereo استفاده نمود. یا به عنوان نمونه طبق جدول زیر می‌توان کتابخانه‌ها را دریافت نمود. مستندات کامل هر کتابخانه نیز در آدرس مربوطه وجود دارد.

ردیف	زبان برنامه‌نویسی	آدرس کتابخانه کلاینت
1	Java	https://github.com/apereo/java-cas-client
2	.Net	https://github.com/apereo/dotnet-cas-client
3	PHP	https://github.com/apereo/phpCAS
4	Python	https://github.com/python-cas/python-cas

همچنین لازم به ذکر است که بسیاری از برنامه‌های متن‌باز مانند Drupal, Mediawiki و … بصورت پیش‌فرض از مدل احراز هویت مبتنی بر CAS استفاده می‌کنند و تنها تنظیماتی که در ادامه این سند ذکر می‌شود برای کارکرد آن‌ها کفایت می‌کند.

کارکرد CAS

در اینجا به نحوه کارکرد CAS می‌پردازیم. در ابتدا اشاره به این نکته ضروری است که سرویس SSO ممکن است به همه برنامه‌ها دسترسی بدهد یا آن‌ را محدود به آدرسهای خاصی کند. بر روی سرویس SSO که در اینجا گفته شده است، دسترسی به آدرسهای مشخصی محدود شده است. بنابراین اگر با خطای زیر مواجه شدید یعنی اینکه دسترسی برای شما برای service URL درخواست شده امکان‌پذیر نیست. در ادامه توضیحات بیشتری در مورد service URL ذکر خواهد شد.

در سمت سرویس مدیریت CAS دو نوع دسترسی اصولاً تعریف می‌شود. اول دسترسی اتصال به سرویس SSO و دوم هم سایر پارامترها و اطلاعاتی که از سمت این سرویس در مورد کاربر به درخواست کننده برگشت داده می‌شود.

در سرویس CAS سه قسمت اصلی وجود دارد:

1. مرورگر کاربر
2. نرم‌افزار تحت وب
3. سرور SSO با پشتیبانی از CAS

مرورگر کاربر

مرورگر کاربر نقش ارتباطی از سمت کاربر را بر عهده دارد و ticket دریافت شده از سمت SSO در مرورگر کاربر ذخیره می‌شود و می‌تواند توسط سایر نرم‌افزارهای سازمان که به SSO متصل هستند، از این ticket جهت اعتبارسنجی نشست فعلی استفاده شود.

نرم‌افزار تحت وب

این نرم‌افزار به عنوان یک CAS client تنظیم شده و برای احراز هویت کاربر در صورت عدم وجود ticket در مرورگر به آدرس مشخصی هدایت می‌شود که بعد از ورود صحیح، کاربر مجدداً به صفحه مشخص شده توسط نرم‌افزار ارجاع داده می‌شود. (تقریباً مشابه آنچیزی که در زمان استفاده از کاربر گوگل برای احراز هویت در سایت‌های دیگر مشاهده می‌کنیم)

سرور SSO با پشتیبانی از CAS

این سرویس از قسمت‌های ذیل تشکیل شده است که به تکمیل این فرآیند کمک می‌کند:

1. ارائه خدمات صفحه ورود و احراز هویت کاربر از یک منبع واحد (دیتابیس، LDAP و غیره)
2. صدور کوکی TG جهت عدم نیاز به ورود مجدد کاربر در موارد بعدی که به سمت سرور CAS هدایت می‌شود (هر نرم‌افزار جهت کنترل اعتبار ورود کاربر، مرورگر را به سمت آدرس وب سرویس CAS هدایت میکند و در صورتی که تیکت کاربر معتبر باشد، مجدداً از سمت CAS کاربر به سامانه اصلی هدایت می‌شود. لذا در این فرآیند کاربری که قبلاً وارد شده است نیازی به ورود مجدد ندارد و متوجه این امر نخواهد شد و این همان سهولتی هست که در کنار امنیت برای کاربر به ارمغان می‌آید)
3. امکان هدایت و برگشت به نرم‌افزار تحت وب با تنظیم ticket=ST-XXX در url مربوطه برای اینکه به عنوان CAS client بتواند تیکت را بررسی کند
4. اعتبارسنجی تیکت صادر شده توسط کتابخانه CAS برای اطمینان نرم‌افزار از صحت ورود کاربر و اعتبار تیکت آن

نحوه اتصال با CAS

در شکل ذیل نحوه اتصال به سرویس CAS مشاهده می‌شود تا بتوانیم بهتر فرآیند آن را درک کنیم.

برای مشاهده دیاگرام‌های دقیق‌تر و بهمراه کد‌های HTTP مربوطه می‌توان به لینک زیر مراجعه کرد

https://apereo.github.io/cas/5.2.x/protocol/CAS-Protocol.html

Initial request (مرحله یک)

1. نرم‌افزار sampleapp به عنوان CAS client تنظیم شده است تا مثلاً روی آدرس test/ احراز هویت را انجام دهد.
2. کاربر از طریق مرورگر به test/ متصل می‌شود.
3. اگر مرورگر در حال حاضر بر روی نرم‌افزار sampleapp هیچ نشستی نداشته باشد، sampleapp کنترل را بدست کتابخانه CAS می‌دهد.
4. اگر کتابخانه CAS پارامتر تیکت را در درخواست مشاهده نکند، کاربر را به صفحه ورود CAS هدایت می‌کند و در انتهای آن عبارت service=url_to_return_to را اضافه می‌کند که این مقدار برابر آدرسی هست که قرار هست بعد از ورود صحیح، کاربر مجدداً به سمت آن هدایت شود.در مثال مد نظر ما مثلاً آدرس http://localhost:8080/sampleapp/test خواهد بود که url نهایی به شکل ذیل هست:

https://accounts.example.com/cas/login?service=http://localhost:8080/sampleapp/test  

اگر این آدرس http://localhost:8080/sampleapp/test در سیستم مدیریت CAS به عنوان آدرس مجاز تعریف نشده باشد پیام Application Not Authorized to Use CAS دیده می‌شود. لذا حتماً بایستی آدرس مد نظر نرم‌افزار خود را به مدیر سیستم اعلام کنید تا در سرویس CAS تعریف شده و دسترسی شما مجاز باشد.

هدایت به صفحه ورود CAS (مرحله دو)

1. کاربر به صفحه ورود CAS جهت احراز هویت انتقال داده می‌شود. فرم ورود مربوط به صفحه CAS روی مرورگر کاربر نمایش داده خواهد شد.
2. در این مرحله کاربر می‌بایست نام کاربری و رمز عبور خود را واردکند. در سمت راست صفحه نیز نام و توضیحات برنامه‌ای که کاربر از آن به سمت صفحه ورود هدایت شده است نمایش داده می‌شود. مانند تصویر زیر:
   
   در تصویر فوق ما از نرم‌افزاری با عنوان CAS Management به این صفحه هدایت شده‌ایم. این موارد توسط مدیر سیستم به عنوان نام و توضیحات نرم‌افزار مجاز تعریف شده، تعیین می‌شود.

بررسی TGT در مرورگر (مرحله سه)

• در این مرحله مقدار CASTGC cookie که در سمت سرور با نام TGT تولید شده است چک می‌شود. اگر چنین مقداری در مرورگر در همان لحظه وجود داشته باشد، یعنی اینکه کاربر توسط CAS قبلاً احراز هویت شده است و از اینجا به مرحله شش خواهد رفت و به نرم‌افزار مجاز با مشخص نمودن مقدار service ticket برگشت داده خواهد شد.
• اگر هیچ CASTGC وجود نداشته باشد، صفحه ورود CAS در مرورگر نمایش داده خواهد شد.

ارسال صفحه ورود به مرورگر توسط CAS (مرحله چهار)

یکی از خوبی‌های این قسمت این مسأله هست که برنامه‌ها نیازی به نمایش صفحه ورود به کاربرها ندارند و همه نرم‌افزارهای سازمان از یک صفحه ورود یکسان استفاده می‌کنند. مشابه آنچه در سیستم SSO گوگل با آدرس https://accounts.google.com مشاهده می‌کنید.

• عدم نیاز به مدیریت صفحه ورود توسط هر نرم‌افزار
• عدم نیاز به اتصال به سیستم‌های بانک اطلاعاتی و یا LDAP و غیره جهت احراز هویت توسط هر نرم‌افزار
• عدم اطلاع از رمز عبور کاربر توسط هر نرم‌افزار. رمز وارد شده توسط کاربر فقط در اختیار مرورگر و سرویس CAS هست که امنیت بالاتری را خواهد داشت

ارسال اطلاعات ورود به سرویس CAS (مرحله پنج)

• سرویس CAS اطلاعاتی که با متود POST توسط مرورگر به آن ارسال شده است را چک می‌کند و اگر احراز هویت انجام نشود مجدداً صفحه ورود را به کاربر نشان می‌دهد.
• تعداد کمی احراز هویت اشتباه در زمان کوتاه باعث قف شدن کاربر می‌شود و سایر احراز هویت‌های بعدی تا ۱۵ دقیقه بدون موفقیت خواهد بود تا از حملات تحت وب جلوگیری شود.

برگشت کاربر به صفحه نرم‌افزار (مرحله شش)

• یک ticket granting ticket که به آن TGT می‌گوییم و به عنوان نمونه مشابه رشته ذیل هست توسط سرویس CAS سمت سرور ذخیره خواهد شد و روی مرورگر نیز یک کوکی با نام CASTGC تنظیم می‌شود.

TGT-1-wKQjkOhweJE6MMTNCqTwv6WojMDBL61GISejnyCfigrMFCumYu-accounts.example.com*

• یک service ticket صادر می‌شود و به عنوان یک پارامتر به آدرس نرم‌افزار ارائه شده در زمان هدایت به CAS برگشت داده می‌شود. (در مرحله یک توضیح داده شده است) این تیکت مشابه زیر خواهد بود. در این مثال فرض شده است که آدرس نرم‌افزار ما http://localhost:8080/sampleapp/test هست

ST-1-bdgbwHIReBonmaudvxJl-accounts.example.com

درخواست مجدد مرورگر برای اتصال به نرم‌افزار بهمراه CAS service ticket (مرحله هفت)

• در حال حاضر هنوز نشست نرم‌افزار کامل برقرار نشده است. در این مرحله کتابخانه CAS وارد عمل کنترل می‌شود.
• کتابخانه CAS پارامتر تیکت را در url مشاهده می‌کند و می‌تواند آن را با سرویس CAS چک کند.
• CAS service ticket تنها یکبار معتبر خواهد بود و کتابخانه CAS می‌تواند از آن ظرف ۹۰ ثانیه استفاده کند و صحت آن را چک کند یا اینکه آن expire خواهد شد و عملیات مرحله شش دوباره می‌بایست انجام شود.

چک صحت CAS service ticket (مرحله هشت)

• کتابخانه CAS برای چک کردن تیکت آماده می‌شود و درخواست زیر را به عنوان نمونه بر حسب آدرس نرم‌افزار ارسال می‌کند:

https://accounts.example.com/cas/serviceValidate?ticket=ST-1-bdgbwHIReBonmaudvxJl-counts.example.com&service=http%3A%2F%2Flocalhost%3A8080%2Fsampleapp%2Ftest%2F  

در صورتی که این تیکت از سمت سرور CAS تأیید شود، کد ۲۰۰ به سمت مرورگر برگشت داده می‌شود.

جواب سرویس CAS به چک صحت ticket (مرحله نه)

• در ذیل یک نمونه جواب CAS را مشاهده می‌کنیم. به مقادیر برگشت داده شده مانند email, lastname, firstname و غیره در تگ cas:attributes توجه کنید. این‌ها همان پارامترهایی از کاربر هستند که به نرم‌افزار مربوطه مجوز مشاهده آن‌ها داده شده است. لذا بسته به نیاز هر برنامه می‌بایست به مدیر سیستم درخواست دهید تا پارامترهای مورد نیاز را در سمت سیستم مدیریت CAS تعریف کند.

  <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationSuccess>
  <cas:user>mohsen</cas:user>
  <cas:attributes>
  <cas:email>mohsen@mbs.co.ir</cas:email>
  <cas:lastname>Saeedi</cas:lastname>
  <cas:firstname>Mohsen</cas:firstname>
  <cas:fullname>Mohsen Saeedi</cas:fullname>
  <cas:uid>0012345678</cas:uid>
  </cas:attributes>
  </cas:authenticationSuccess>
  </cas:serviceResponse>

ارسال صفحه نرم‌افزار (مرحله ده)

• در این مرحله کاربر به صفحه نهایی هدایت می‌شود و می‌تواند از نرم‌افزار sampleapp استفاده کند.

تنظیمات CAS client

در کتابخانه‌های زبانهایی که برنامه CAS client را دارند، فایل تنظیماتی بسته به نوع زبان وجود دارد که آدرس سرویس‌دهنده و سایر پارامترهای مربوطه را می‌توان در آن تنظیم نمود. جهت این مسأله به مستندات کتابخانه CAS مربوطه می‌توان رجوع کرد. در زمان ارتباط با سرویس CAS اطلاعات مربوط به اتصال و آدرس آن توسط مدیر سیستم در اختیار شما قرار خواهد گرفت.

نحوه اتصال با RESTful

پروتکل REST این امکان را به سایر برنامه ها می دهد که به جای استفاده از گواهی نامه های SSL برای تایید اعتبار از CAS برای پذیرش تیکت استفاده کنند.

تنظیمات

با جایگشت موارد زیر پشتیبانی می شود.

compile "org.apereo.cas:cas-server-support-rest:${project.'cas.version'}"

درخواست یک TGT

POST /cas/v1/tickets HTTP/1.0
username=battags&password=password&additionalParam1=paramvalue

پاسخ موفق

201 Created
Location: http://www.whatever.com/cas/v1/tickets/{TGT  id}

پاسخ ناموفق

اگر اعتبار نادرست ارسال شود، CAS با خطای 400bad request error پاسخ می دهد.

اگر یک نوع رسانه که آن را نمی فهمد ارسال شود، با خطای 415unsupported media type پاسخ می دهد.

JWT Ticket Granting Tickets

TGT ای که توسط پروتکل REST ایجاد شده به عنوان JWT صادر می شوند. با جایگشت موارد زیر پشتیبانی می شود.

compile       "org.apereo.cas:cas-server-support-rest-
tokens:${project.'cas.version'}"

برای درخواست اعطای TGT به عنوان JWT بعدی ، مطمئن شوید که درخواست POST با موارد زیر مطابقت دارد:

POST /cas/v1/tickets HTTP/1.0
username=battags&password=password&token=true&additionalParam1=paramvalue

پارامتر توکن به عنوان پارامتر درخواست یا یک هدر درخواست ارسال می شود. قسمت پاسخ شامل TGT به عنوان یک JWT خواهد بود. توجه داشته باشید که JWT های ایجاد شده معمولا با کلیدهای از پیش تولید شده رمزگذاری می شوند. برای تنظیمات ودیدن لیست مربوط به property های CAST این راهنما را مرور کنید.

درخواست یک Service Ticket

POST /cas/v1/tickets/{TGT id} HTTP/1.0
service={form encoded parameter for the service url}

پاسخ موفق

200 OK
ST-1-FFDFHDSJKHSDFJKSDHFJKRUEYREWUIFSD2132

JWT Service Tickets

service ticket های ایجاد شده توسط پروتکل REST به عنوان JWT صادر می شوند. برای کسب اطلاعات بیشتر به این راهنما مراجعه کنید.

با جایگشت موارد زیر پشتیبانی می شود:

compile              "org.apereo.cas:cas-server-support-rest-
tokens:${project.'cas.version'}"

اعتبار Service Ticket

از طریق پروتکل CAS توسط p3/serviceValidate انجام می شود.

GET /cas/p3/serviceValidate?service={service url}&ticket={service ticket}

پاسخ ناموفق

CAS یک خطای 400Bad Request ارسال می کند. اگر هم یک نوع رسانه نادرست ارسال شود خطای 415Unsupported Media Type ارسال می کند.

logout

با حذف تیکت صادر شده، نشست SSO پایان می یابد.

DELETE /cas/v1/tickets/TGT-fdsjfsdfjkalfewrihfdhfaie HTTP/1.0

وضعیت تیکت

وضعیت تیکت را بررسی کنید و مطمئن شوید که هنوز معتبر است و منقضی نشده است.

GET /cas/v1/tickets/TGT-fdsjfsdfjkalfewrihfdhfaie HTTP/1.0

پاسخ موفق

200 OK

پاسخ ناموفق

404 NOT FOUND

اضافه کردن سرویس

با جایگشت موارد زیر پشتیبانی می شود:

compile           "org.apereo.cas:cas-server-support-rest-
services:${project.'cas.version'}"

به CAS برای ثبت برنامه ها در رجیستری سرویس خود درخواست دهید. REST باید تایید شود زیرا به TGT از سرور CAS احتیاج دارد و علاوه بر این، تصدیق اصلی که درخواست را ارسال می کند باید با یک مقدار و pre-configured role name در تنظیمات CAS مجاز باشد. برای دیدن لیست مربوط به property های CAS، لطفا این راهنما را مرور کنید.

POST /cas/v1/services/add/{TGT id} HTTP/1.0
serviceId=svcid&name=svcname&description=svcdesc&evaluationOrder=1234&enabled=true&ssoEnabled=true

پاسخ موفق

اگر درخواست موفق باشد، مقدار برگشتی در پاسخ، شناسه تولید شده سرویس است.

200 OK
5463544213

---

مرجع