Aracılığıyla paylaş

Veri API'si oluşturucusunda yetkilendirme ve roller

Veri API'si oluşturucusu rol tabanlı yetkilendirme iş akışı kullanır. Kimliği doğrulanmış veya doğrulanmamış tüm gelen istekler bir role atanır. Roller Sistem Rolleri veya Kullanıcı Rolleri olabilir. Atanan rol daha sonra, istenen varlıkta söz konusu rol için hangi eylemlerin, alanların ve ilkelerin kullanılabilir olduğunu anlamak için yapılandırmada belirtilen tanımlı izinlere göre denetlenebilir.

Kullanıcının rolünü belirleme

Hayır role varsayılan izinlere sahiptir. Bir kural Veri API oluşturucusu tarafından belirlendikten sonra, isteğin başarılı olması için varlığın permissions bu rolü tanımlaması actions gerekir.

Sağlanan Belirteç x-ms-api-role Sağlanan x-ms-api-role Token'de Sonuçta Elde Edilen Rol
Hayı Hayı Hayı anonymous
Evet Hayı Hayı authenticated
Evet Evet Hayı İstisna
Evet Evet Evet x-ms-api-role değer

anonymous veya authenticated dışında bir role sahip olmak için x-ms-api-role üst bilgisi gereklidir.

Uyarı

bir isteğin yalnızca bir rolü olabilir. Belirteç birden çok rol belirtse bile, x-ms-api-role değer isteğe hangi rolün atandığı seçer.

Sistem rolleri

Sistem rolleri, Veri API'si oluşturucusu tarafından tanınan yerleşik rollerdir. Sistem rolü, istek sahibinin erişim belirteçlerinde belirtilen rol üyeliğinden bağımsız olarak istek sahibine otomatik olarak atanır. İki sistem rolü vardır: anonymous ve authenticated.

Anonim sistem rolü

Sistem anonymous rolü, kimliği doğrulanmamış kullanıcılar tarafından yürütülen isteklere atanır. Kimliği doğrulanmamış erişim isteniyorsa çalışma zamanı yapılandırma tanımlı varlıkların anonymous rol izinleri içermesi gerekir.

Örnek

Aşağıdaki Veri API'si oluşturucu çalışma zamanı yapılandırmasında, sistem rolünün anonymous Kitap varlığına okuma erişimi içerecek şekilde açıkça yapılandırılması gösterilmektedir:

"Book": {
    "source": "books",
    "permissions": [
        {
            "role": "anonymous",
            "actions": [ "read" ]
        }
    ]
}

İstemci uygulaması kimliği doğrulanmamış bir kullanıcı adına Book varlığına erişen bir istek gönderdiğinde, uygulama HTTP üst bilgisini içermemelidir Authorization .

Kimliği doğrulanmış sistem rolü

Sistem authenticated rolü, kimliği doğrulanmış kullanıcılar tarafından yürütülen isteklere atanır.

Örnek

Aşağıdaki Veri API'si oluşturucu çalışma zamanı yapılandırmasında, sistem rolünün authenticated Kitap varlığına okuma erişimi içerecek şekilde açıkça yapılandırılması gösterilmektedir:

"Book": {
    "source": "books",
    "permissions": [
        {
            "role": "authenticated",
            "actions": [ "read" ]
        }
    ]
}

Kullanıcı rolleri

Kullanıcı rolleri, çalışma zamanı yapılandırmasında ayarladığınız kimlik sağlayıcısındaki kullanıcılara atanan sistem dışı rollerdir. Veri API'sinin oluşturucusunun bir isteği kullanıcı rolü bağlamında değerlendirmesi için iki gereksinimin karşılanması gerekir:

  1. İstemci uygulaması tarafından sağlanan erişim belirteci, kullanıcının rol üyeliğini listeleyen rol taleplerini içermelidir.
  2. İstemci uygulaması, HTTP üst bilgisini X-MS-API-ROLE ile isteklerde içermeli ve üst bilginin değerini istenen kullanıcı rolü olarak ayarlamalıdır.

Rol değerlendirme örneği

Aşağıdaki örnek, Data API builder çalışma zamanı yapılandırmasında yapılandırılan varlığa yapılan Book istekleri aşağıda gösterildiği gibi gösterir:

"Book": {
    "source": "books",
    "permissions": [
        {
            "role": "anonymous",
            "actions": [ "read" ]
        },
        {
            "role": "authenticated",
            "actions": [ "read" ]
        },
        {
            "role": "author",
            "actions": [ "read" ]
        }
    ]
}

Statik Web Apps'te kullanıcı varsayılan olarak anonim rolün bir üyesidir. Kullanıcının kimliği doğrulanmışsa, kullanıcı hem anonymous hem de authenticated rollerinin üyesi olur.

İstemci uygulaması , Statik Web Apps veritabanı bağlantıları (Önizleme) kullanılarak dağıtılan Veri API oluşturucusuna kimliği doğrulanmış bir istek gönderdiğinde, istemci uygulaması Static Web Apps'in JSON'a dönüştürdüğü bir erişim belirteci sağlar:

{
  "identityProvider": "azuread",
  "userId": "d75b260a64504067bfc5b2905e3b8182",
  "userDetails": "username",
  "userRoles": ["anonymous", "authenticated", "author"]
}

Veri API oluşturucusu istekleri tek bir rol bağlamında değerlendirdiğinden, isteği varsayılan olarak sistem rolü authenticated bağlamında değerlendirir.

İstemci uygulamasının isteği, değer olarak X-MS-API-ROLE ile birlikte HTTP üst bilgisini author içeriyorsa, istek author rol bağlamında değerlendirilir. Erişim belirteci ve X-MS-API-ROLE HTTP üst bilgisi de dahil olmak üzere örnek istek:

curl -k -r GET -H 'Authorization: Bearer ey...' -H 'X-MS-API-ROLE: author' https://localhost:5001/api/Book

Önemli

Sağlanan erişim belirtecinin roles talebi üst bilgide listelenen rolü içermediğinde istemci uygulamasının X-MS-API-ROLE isteği reddedilir.

İzinler

İzinler şu şekilde açıklanmaktadır:

  • Kim rol üyeliğine göre bir varlık üzerinde istekte bulunabilir?
  • Kullanıcının gerçekleştirebileceği eylemler (oluşturma, okuma, güncelleştirme, silme, yürütme)
  • Belirli bir eylem için hangi alanlara erişilebilir?
  • İstek tarafından döndürülen sonuçlarda hangi ek kısıtlamalar var?

İzinleri tanımlama söz dizimi çalışma zamanı yapılandırma makalesinde açıklanmıştır.

Önemli

Tek bir varlığın izin yapılandırmasında birden çok rol tanımlanmış olabilir. Ancak istek yalnızca tek bir rol bağlamında değerlendirilir:

  • Varsayılan olarak, sistem rolü anonymous veya authenticated
  • Eklendiğinde, X-MS-API-ROLE rolü HTTP üst bilgisine ayarlanır.

Varsayılan olarak güvenli

Varsayılan olarak, bir varlığın yapılandırılmış izni yoktur ve bu da hiç kimsenin varlığa erişe olmadığı anlamına gelir. Ayrıca, Veri API oluşturucusu çalışma zamanı yapılandırmasında başvurulmuyorsa veritabanı nesnelerini yoksayar.

İzinler açıkça yapılandırılmalıdır

Bir varlığa kimliği doğrulanmamış erişime izin vermek için rolün anonymous varlığın izinlerinde açıkça tanımlanması gerekir. Örneğin, varlığın book izinleri kimliği doğrulanmamış okuma erişimine izin verecek şekilde açıkça ayarlanır:

"book": {
  "source": "dbo.books",
  "permissions": [{
    "role": "anonymous",
    "actions": [ "read" ]
  }]
}

Bir varlık üzerindeki izin tanımını basitleştirmek için, eğer authenticated rolü için belirli izinler yoksa, anonymous rolü için tanımlanan izinlerin kullanıldığını varsayalım. Daha önce gösterilen book yapılandırma, anonim ya da kimliği doğrulanmış kullanıcıların book varlık üzerinde okuma işlemleri yapmasına izin verir.

Okuma işlemlerinin yalnızca kimliği doğrulanmış kullanıcılarla sınırlandırılması gerektiğinde, aşağıdaki izin yapılandırması ayarlanmalıdır ve bu da kimliği doğrulanmamış isteklerin reddedilmesine neden olur:

"book": {
  "source": "dbo.books",
  "permissions": [{
    "role": "authenticated",
    "actions": [ "read" ]
  }]
}

Bir varlık, anonymous ve authenticated rolleri için izin gerektirmez ve önceden yapılandırılmamıştır. Bir varlığın izin yapılandırmasında bir veya daha fazla kullanıcı rolü tanımlanabilir ve tanımlanan diğer tüm tanımlanmamış rollere, sisteme veya kullanıcıya erişim otomatik olarak reddedilir.

Aşağıdaki örnekte, varlık için administrator tanımlanan tek rol kullanıcı rolüdürbook. Kullanıcının, administrator rolünün bir üyesi olması ve X-MS-API-ROLE varlığı üzerinde işlem yapabilmesi için bu rolü book HTTP üst bilgisine eklemesi gerekir.

"book": {
  "source": "dbo.books",
  "permissions": [{
    "role": "administrator",
    "actions": [ "*" ]
  }]
}

Uyarı

Azure Cosmos DB ile Veri API oluşturucusu kullanılırken GraphQL sorgularında erişim denetimini zorunlu kılmak için sağlanan @authorize yönergesini kullanmanız gerekir. Ancak GraphQL sorgularındaki GraphQL mutasyonları ve filtreleri için erişim denetimi, daha önce açıklandığı gibi izin yapılandırması tarafından yine de uygulanır.

Eylemler

Eylemler , bir rolün kapsamındaki bir varlığın erişilebilirliğini açıklar. Eylemler tek tek veya joker karakter kısayoluyla belirtilebilir: * (yıldız işareti). Joker karakter kısayolu, varlık türü için desteklenen eylemlerin tümünü temsil eder:

  • Tablolar ve Görünümler: create, read, update, delete
  • Saklanan Prosedürler: execute

Eylemler hakkında daha fazla bilgi için yapılandırma dosyası belgelerine bakın.

Alan erişimi

Eylem için hangi alanların erişilebilir olacağını yapılandırabilirsiniz. Örneğin, eyleme dahil etmek ve eylemdenread dışlamak için hangi alanları ayarlayabilirsiniz.

Aşağıdaki örnek, free-access rolündeki kullanıcıların Column3 üzerinde okuma işlemleri gerçekleştirmesini engeller. GET isteklerindeki (REST uç noktası) veya sorgulardaki (GraphQL uç noktası) Column3 referansları, isteğin reddedilmesiyle sonuçlanır:

    "book": {
      "source": "dbo.books",
      "permissions": [
        {
          "role": "free-access",
          "actions": [
            "create",
            "update",
            "delete",
            {
              "action": "read",
              "fields": {
                "include": [ "Column1", "Column2" ],
                "exclude": [ "Column3" ]
              }
            }
          ]
        }
      ]
    }

Uyarı

Azure Cosmos DB ile Veri API oluşturucusu kullanılırken GraphQL sorgularında erişim denetimini zorunlu kılmak için sağlanan @authorize yönergesini kullanmanız gerekir. Ancak GraphQL sorgularındaki GraphQL mutasyonları ve filtreleri için erişim denetimi, burada açıklandığı gibi izin yapılandırması tarafından yine de uygulanır.

Öğe düzeyi güvenlik

Veritabanı ilkesi ifadeleri, sonuçların daha da kısıtlanmalarını sağlar. Veritabanı ilkeleri, ifadeleri veritabanında yürütülen sorgu önkoşullarına çevirir. Veritabanı ilkesi ifadeleri aşağıdaki eylemler için desteklenir:

  • yaratmak
  • okumak
  • güncelleştirmek
  • silmek

Uyarı

Saklı yordamlarla kullanılan yürütme eylemi, veritabanı ilkelerini desteklemez .

Uyarı

Veritabanı ilkeleri şu anda NoSQL için CosmosDB tarafından desteklenmemektedir.

Veritabanı ilkeleri hakkında daha fazla bilgi için yapılandırma dosyası belgelerine bakın.

Örnek

Roldeki readconsumer eylemi yalnızca başlığın "Örnek Başlık" olduğu kayıtları döndürecek şekilde kısıtlayan bir veritabanı ilkesi.

{
  "role": "consumer",
  "actions": [
    {
      "action": "read",
      "policy": {
        "database": "@item.title eq 'Sample Title'"
      }
    }
  ]
}

İlgili içerik

  • Last updated on