سیاست های اظهارنظر SAMLA

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

چه

• احراز هویت و مجوز ورودی: اعتبارسنجی سیاست ادعای SAML
  نوع سیاست SAML به پروکسی‌های API این امکان را می‌دهد که ادعاهای SAML پیوست‌شده به درخواست‌های SOAP ورودی را اعتبارسنجی کنند. سیاست SAML پیام‌های ورودی حاوی یک ادعای SAML با امضای دیجیتالی را اعتبارسنجی می‌کند، در صورت نامعتبر بودن آنها را رد می‌کند و متغیرهایی را تنظیم می‌کند که به سیاست‌های اضافی یا خود سرویس‌های backend اجازه می‌دهد تا اطلاعات موجود در ادعا را بیشتر اعتبارسنجی کنند.
• تولید توکن خروجی: ایجاد سیاست ادعای SAML
  نوع سیاست SAML به پروکسی‌های API این امکان را می‌دهد که ادعاهای SAML را به درخواست‌های XML خروجی ضمیمه کنند. سپس این ادعاها برای فعال کردن سرویس‌های backend جهت اعمال پردازش‌های امنیتی بیشتر برای احراز هویت و مجوز در دسترس قرار می‌گیرند.

نمونه‌ها

<GenerateSAMLAssertion name="SAML" ignoreContentType="false">
  <CanonicalizationAlgorithm />
  <Issuer ref="reference">Issuer name</Issuer>
  <KeyStore>
    <Name ref="reference">keystorename</Name>
    <Alias ref="reference">alias</Alias>
  </KeyStore>
  <OutputVariable>
    <FlowVariable>assertion.content</FlowVariable>
    <Message name="request">
      <Namespaces>
        <Namespace prefix="test">http://www.example.com/test</Namespace>
      </Namespaces>
      <XPath>/envelope/header</XPath>
    </Message>
  </OutputVariable>
  <SignatureAlgorithm />
  <Subject ref="reference">Subject name</Subject>
  <Template ignoreUnresolvedVariables="false">
    <!-- A lot of XML goes here, in CDATA, with {} around
         each variable -->
  </Template>
</GenerateSAMLAssertion>

<ValidateSAMLAssertion name="SAML" ignoreContentType="false">
  <Source name="request">
    <Namespaces>
      <Namespace prefix='soap'>http://schemas.xmlsoap.org/soap/envelope/</Namespace>
      <Namespace prefix='wsse'>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</Namespace>
      <Namespace prefix='saml'>urn:oasis:names:tc:SAML:2.0:assertion</Namespace>
    </Namespaces>
    <AssertionXPath>/soap:Envelope/soap:Header/wsse:Security/saml:Assertion</AssertionXPath>
    <SignedElementXPath>/soap:Envelope/soap:Header/wsse:Security/saml:Assertion</SignedElementXPath>
  </Source>
  <TrustStore>TrustStoreName</TrustStore>
  <RemoveAssertion>false</RemoveAssertion>
</ValidateSAMLAssertion>

مرجع عنصر

تولید ادعای SAML

اعتبارسنجی ادعای SAML

یادداشت‌های استفاده

مشخصات زبان نشانه‌گذاری ادعای امنیتی (SAML) فرمت‌ها و پروتکل‌هایی را تعریف می‌کند که برنامه‌ها را قادر می‌سازد اطلاعات با فرمت XML را برای احراز هویت و مجوز مبادله کنند.

«ادعای امنیتی» یک توکن قابل اعتماد است که ویژگی یک برنامه، کاربر برنامه یا برخی دیگر از شرکت‌کنندگان در یک تراکنش را توصیف می‌کند. ادعاهای امنیتی توسط دو نوع موجودیت مدیریت و مصرف می‌شوند:

• ارائه دهندگان هویت: ایجاد ادعاهای امنیتی از طرف شرکت کنندگان
• ارائه دهندگان خدمات: اعتبارسنجی ادعاهای امنیتی از طریق روابط قابل اعتماد با ارائه دهندگان هویت

پلتفرم API می‌تواند به عنوان یک ارائه‌دهنده هویت و یک ارائه‌دهنده سرویس عمل کند. این پلتفرم با تولید assertionها و پیوست کردن آنها به پیام‌های درخواست، به عنوان یک ارائه‌دهنده هویت عمل می‌کند و این assertionها را برای پردازش توسط سرویس‌های backend در دسترس قرار می‌دهد. این پلتفرم با اعتبارسنجی assertionها در پیام‌های درخواست ورودی، به عنوان یک ارائه‌دهنده سرویس عمل می‌کند.

نوع سیاست SAML از ادعاهای SAML پشتیبانی می‌کند که با نسخه ۲.۰ از مشخصات اصلی SAML و نسخه ۱.۰ از مشخصات پروفایل توکن SAML WS-Security مطابقت دارند.

تولید ادعای SAML

پردازش سیاست:

1. اگر پیام XML نیست و IgnoreContentType روی true تنظیم نشده است، آنگاه یک خطا ایجاد می‌شود.
2. اگر "Template" تنظیم شده باشد، آن را مطابق با توضیحات مربوط به سیاست AssignMessage پردازش کنید. اگر هر متغیری از دست رفته باشد و IgnoreUnresolvedVariables تنظیم نشده باشد، یک خطا ایجاد کنید.
3. اگر «الگو» تنظیم نشده باشد، یک ادعا (asser) بسازید که شامل مقادیر پارامترهای موضوع (Subject) و صادرکننده (Former) یا ارجاعات آنها باشد.
4. با استفاده از کلید مشخص شده، بیانیه را امضا کنید.
5. عبارت تاکیدی را در XPath مشخص شده به پیام اضافه کنید.

اعتبارسنجی ادعای SAML

پردازش سیاست:

1. این خط‌مشی، پیام ورودی را بررسی می‌کند تا تأیید کند که نوع رسانه درخواست XML است، و این کار را با بررسی اینکه آیا نوع محتوا با فرمت‌های text/(.*+)?xml یا application/(.*+)?xml مطابقت دارد یا خیر، انجام می‌دهد. اگر نوع رسانه XML نباشد و <IgnoreContentType> تنظیم نشده باشد، خط‌مشی خطایی ایجاد می‌کند.
2. این سیاست، XML را تجزیه و تحلیل می‌کند. اگر تجزیه با شکست مواجه شود، خطایی رخ می‌دهد.
3. این سیاست، عنصر امضا شده و ادعا را با استفاده از XPath های مربوطه مشخص شده ( <SignedElementXPath> و <AssertionXPath> ) استخراج می‌کند. اگر هر یک از این مسیرها عنصری را برنگردانند، در آن صورت این سیاست یک خطا ایجاد می‌کند.
4. این سیاست بررسی می‌کند که آیا عبارت Assertion با عنصر امضا شده یکسان است یا فرزند عنصر امضا شده است. اگر این درست نباشد، سیاست یک خطا (fault) ایجاد می‌کند.
5. اگر هر یک از عناصر <NotBefore> یا <NotOnOrAfter> در ادعا وجود داشته باشند، این خط‌مشی، مهر زمانی فعلی را با این مقادیر، همانطور که در بخش ۲.۵.۱ از SAML Core توضیح داده شده است، بررسی خواهد کرد.
6. این خط‌مشی، هرگونه قانون اضافی برای پردازش «شرایط» را مطابق آنچه در بخش ۲.۵.۱.۱ از SAML Core شرح داده شده است، اعمال خواهد کرد.
7. این خط‌مشی، امضای دیجیتال XML را با استفاده از مقدار ذخیره اعتماد ( <TrustStore> ) که در بالا توضیح داده شد، اعتبارسنجی می‌کند. اگر اعتبارسنجی با شکست مواجه شود، خط‌مشی خطایی را ایجاد می‌کند.

پس از اتمام خط‌مشی بدون بروز خطا، توسعه‌دهنده پروکسی می‌تواند از موارد زیر مطمئن باشد:

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

سیاست‌های دیگری مانند ExtractVariables ممکن است برای تجزیه XML خام ادعا برای اعتبارسنجی پیچیده‌تر استفاده شوند.

متغیرهای جریان

اطلاعات زیادی وجود دارد که ممکن است در یک ادعای SAML مشخص شود. خود ادعای SAML یک XML است که می‌تواند با استفاده از سیاست ExtractVariables و سایر مکانیسم‌ها تجزیه شود تا اعتبارسنجی‌های پیچیده‌تری پیاده‌سازی شوند.

مرجع خطا

این بخش کدهای خطا و پیام‌های خطایی را که برگردانده می‌شوند و متغیرهای خطا را که توسط Edge تنظیم می‌شوند، هنگامی که این خط‌مشی خطا را راه‌اندازی می‌کند، توضیح می‌دهد. این اطلاعات برای دانستن اینکه آیا در حال توسعه قوانین خطا برای رسیدگی به خطاها هستید، مهم است. برای کسب اطلاعات بیشتر، آنچه را که باید در مورد خطاهای خط مشی و مدیریت خطاها بدانید را ببینید.

خطاهای استقرار

این خطاها ممکن است زمانی رخ دهند که یک پروکسی حاوی این خط مشی را مستقر می کنید.

متغیرهای خطا

این متغیرها زمانی تنظیم می شوند که یک خطای زمان اجرا رخ دهد. برای اطلاعات بیشتر، به آنچه باید در مورد خطاهای خط مشی بدانید مراجعه کنید.

نمونه پاسخ خطا

{
  "fault": {
    "faultstring": "GenerateSAMLAssertion[GenSAMLAssert]: Invalid media type",
    "detail": {
      "errorcode": "steps.saml.generate.InvalidMediaTpe"
    }
  }
}

مثال قانون خطا

<FaultRules>
    <FaultRule name="invalid_saml_rule">
        <Step>
            <Name>invalid-saml</Name>
        </Step>
        <Condition>(GenerateSAMLAssertion.failed = "true")</Condition>
    </FaultRule>
</FaultRules>

مباحث مرتبط

استخراج متغیرها: سیاست استخراج متغیرها