6.2.10. Doğrulama türleri

<< Prev   Next >>

6.2.10.1. Genel bilgiler

Doğrulama, sağlanan kimliğin (ad) kullanıcıya ait olup olmadığını doğrulayan bir prosedürdür. 1C:Enterprise, sonraki bölümlerde açıklanan birden fazla doğrulama türünü destekler.

6.2.10.2. 1C:Enterprise doğrulaması

Kullanıcı, kullanıcı adı ve parola sağlanarak (kimlik doğrulama iletişim kutusuna yazılır, komut satırı parametreleri olarak aktarılır veya harici bir bağlantı veya otomasyon sunucusu için Infobase bağlantı dizesinde aktarılır) 1C:Enterprise tarafından doğrulanabilir. Bu durumda, kullanıcı adı ve parola doğrulaması 1C:Enterprise tarafından gerçekleştirilir.

6.2.10.3. İşletim sistemi kimlik doğrulaması

Kullanıcı, işletim sistemi fonksiyonu örtük olarak kullanılarak doğrulanabilir. Bu doğrulama türünü etkinleştirmek için 1C:Enterprise kullanıcısını bir işletim sistemi kullanıcısı ile eşleştirmeniz gerekir. Başlangıçta, 1C:Enterprise işletim sisteminden o anda kimliği doğrulanmış işletim sistemi kullanıcısı hakkında bilgi ister. Bu amaçla Windows SSPI arayüzünü, Linux ise GSS-API'yı kullanır. Ardından işletim sistemi kullanıcısı ve 1C:Enterprise kullanıcısı arasındaki eşleşme doğrulanır. Eşleşen kullanıcı bulunursa 1C:Enterprise kullanıcısı doğrulanır ve doğrulama iletişim kutusu görüntülenmez.

İşletim sistemi kullanıcısını şu şekilde belirtin: \\domain_name\username. Kullanıcı adı yalnızca Latin harflerini içerir. Etki alanı adı ve kullanıcı adı formatı etki alanı denetleyicisinin ve hesaplarının ayarlarına bağlıdır. İşletim sistemi kullanıcısının doğru adı, teknolojik günlükte CONN olayının kayıtlarında bulunabilir. Srvr: DstUserName2 ile başlayan Txt özelliğini arayın. Örneğin, 30:30.551013-0,CONN,2,process=rmngr,OSThread=24204,t:clientID=3,Txt=Srvr: DstUserName2: d1.d2\user1(d1.d2\user1) olayı, Infobase kullanıcı tanımında işletim sistemi kullanıcı adını \\d1.d2\user1 olarak belirtmeniz gerektiği anlamına gelir.

Zorlanmış 1C:Enterprise doğrulaması gerektiğinde, istemci uygulamanın başlangıç komut satırında /WA- komut satırı parametresini belirtin. /WA- komut satırı parametresi, işletim sistemi kimlik doğrulamasını zorlar (varsayılan olarak etkinleştirilmiştir).

Ayrıca bkz.:

• Teknolojik günlük

6.2.10.4. OpenID kimlik doğrulaması

OpenID (https://openid.net/), bir kullanıcının tek bir hesap kullanarak birçok ilişkisiz kaynakta, sistemde vb. kimlik doğrulaması yapmasını sağlayan bir protokoldür. 1C:Enterprise, Direct Identity modeli altında OpenID 2.0 tabanlı bir protokol kullanır.

Genel prosedür aşağıdaki gibidir:

• Kullanıcı 1C:Enterprise'a giriş yapmaya çalışır.
• 1C:Enterprise, default.vrd yayın dosyasını kullanarak Infobase için OpenID kimlik doğrulamasının etkinleştirildiğini tanımlar.
• Doğrulama isteği, OpenID sağlayıcısına gönderilir. OpenID sağlayıcısı, Infobase yayınının adresinden gelen istekleri alabilmelidir.
• Etkileşimli bir işlem gerekiyorsa (örneğin, bu kullanıcı kimliği için ilk doğrulama gerçekleştiriliyorsa veya kullanıcı kimlik doğrulama verilerinin süresi dolmuşsa) sağlayıcı, 1C:Enterprise'a kullanıcı adı ve parolanın gerekli olduğunu bildirir. 1C:Enterprise etkileşimli işlemi gerçekleştirir ve OpenID sağlayıcısına istenen verileri döndürür.

  Kullanıcı kimlik doğrulama verileri, web tarayıcı deposundaki çerez dosyalarında saklanır. İnce istemci kendi deposunu kullanır.

• Sağlayıcı, kullanıcıyı doğrularsa 1C:Enterprise'a kullanıcının doğrulandığını gösteren bir bayrak döndürür.

OpenID kimlik doğrulaması, Infobase'e yalnızca HTTP veya HTTPS üzerinden erişim sağlanırsa çalışır. Bu durum, OpenID kimlik doğrulamasının yalnızca web sunucusu aracılığıyla Infobase'e bağlanan web istemcisi, mobil istemci ve ince istemci ile kullanılabilir olduğu anlamına gelir. OpenID kimlik doğrulaması üzerine, ince istemci veya Mozilla Firefox, Google Chrome ve Safari kullanılırsa etki alanları arası istekler olabilir.

Bir OpenID sağlayıcısı, bir sunucuda özel bir şekilde yayınlanan bir 1C:Enterprise Infobase'e veya OpenID Authentication 2.0'a ve bu protokolün 1C:Enterprise platformunda uygulanan uzantısına sahip bir bilgi sistemi olabilir. Bir OpenID sağlayıcısının istemcisi olan bir Infobase yayınlanırken, OpenID sağlayıcısının adresi default.vrd dosyasında (<rely> öğesi) belirtilir.

1C:Enterprise Infobase kullanıcısı ile OpenID sağlayıcı kullanıcısını eşleştirmek için kullanılan temel alanın, Infobase kullanıcısının Ad özelliğinde belirtilen bir değer olduğu vurgulanmalıdır. Başka bir deyişle, Infobase'deki Ad özelliği OpenID sağlayıcısı tarafından döndürülen bir kimlik içeriyorsa bir kullanıcı Infobase'de oturum açabilir. Döndürülecek kimlik tanımı için kullanılan OpenID sağlayıcısının belgelerine bakın.

Kullanıcı parolası OpenID sağlayıcısında ayarlanır. Bir 1C:Enterprise Infobase'i, OpenID sağlayıcısı olarak çalışıyorsa parola bu Infobase'de ayarlanır. OpenID sağlayıcısının istemcisi olarak çalışan Infobase'de ayarlanan parola, OpenID kimlik doğrulaması sırasında yok sayılır. Bir üçüncü taraf OpenID sağlayıcısı kullanılırsa parola bu sağlayıcı tarafından ayarlanır. Kullanıcı parolası, OpenID sağlayıcısı kullanıcı deposunda değiştirildikten sonra 1C:Enterprise aşağıdaki kuralları izler:

• Kullanıcı, oturumlar sonlandırılana kadar devam eden tüm oturumlarda kimliği doğrulanmış olarak kabul edilir.
• Yeni bir oturum oluştururken, kullanıcı kimlik doğrulama verilerinin süresi henüz dolmamış olsa bile kullanıcıdan parola istenir.

Zorlanmış OpenID kimlik doğrulaması gerektiğinde, istemi uygulamasının başlangıç komut satırında /OIDA+ komut satırı parametresini (varsayılan olarak etkinleştirilir) belirtin. OpenID kimlik doğrulamasını devre dışı bırakmaya zorlamak için /OIDA komut satırı parametresi kullanılır.

OpenID kimlik doğrulamasını desteklemesi için web sunucusunu yapılandırma hakkında daha fazla bilgi için bkz. OpenID kimlik doğrulaması destek ayarları.

Ayrıca bkz.:

• OpenID Authentication 2.0 (bkz. https://openid.net/specs/openid-authentication-2_0.html).
• Bir OpenID sağlayıcısı için ek gereklilikler

6.2.10.5. OpenID Connect kimlik doğrulaması

OpenID Connect (https://openid.net/connect/) OAuth 2.0 kimlik doğrulama protokolünün uzantısı olan bir protokoldür. OpenID Connect, 1C:Enterprise'ın üçüncü taraf sağlayıcı tarafından yapılan kimlik doğrulamasına dayanarak kullanıcı kimliklerini doğrulamasını sağlar. Bu protokol ince, mobil veya web istemcisi kullanılırken uygulanabilir. 1C:Enterprise, OpenID Connect sağlayıcısı olamaz. Bu amaçla üçüncü taraf sağlayıcılar kullanılır. OpenID Connect protokol desteği aynı zamanda Tanımlama ve Kimlik Doğrulama için Birleşik Sistem'i (USIA) kullanma seçeneği anlamına gelir.

1C:Enterprise kullanıcıları ile kimlik doğrulama sağlayıcısı kullanıcılarını eşleştirmek için aşağıdaki veriler kullanılır:

• Kimlik doğrulama sağlayıcısı tarafında, varsayılan olarak e-posta adresi anahtar parametre olarak kullanılır. OpenID Connect sağlayıcısına erişimi ayarlarken, anahtar alan olarak kullanılacak bir kimlik doğrulama belirteç alanı belirtebilirsiniz.
• 1C:Enterprise tarafında ise anahtar parametre, varsayılan olarak Infobase kullanıcısının Ad özelliğinde yer alır. OSUser veya Email özelliğini ve ayrıca UserMatchingKeys koleksiyonundan bir değeri anahtar alan olarak ayarlayabilirsiniz.

Eşleştirme için UserMatchingKeys koleksiyonu kullanılıyorsa, bunu yalnızca 1C:Enterprise dilini kullanarak doldurabilirsiniz. Kod bu şekilde olabilir:

IBUser = InfobaseUsers.Find(UserCode);
IBUser. UserMatchingKeys.Insert("googleIV", "user-name@google.com");
IBUser.Write()

UserMatchingKeys toplama öğesi, default.vrd dosyasındaki sağlayıcı listesi, name özelliği googleIV değerine eşit olan bir sağlayıcının açıklamasını içeriyorsa kullanılır. OpenID Connect sağlayıcısı tarafından döndürülen belirteçten eşleştirme alanı değeri user-name@google.com ise, UserCode değişken değeri tarafından tanımlanan kullanıcı, oturum başlangıcında kullanılacaktır. default.vrd dosyasının openidconnect.providers öğesi için örnekteki googleIV sağlayıcı ayrıntılarına bakınız.

Bir mobil istemci söz konusu olduğunda, kimlik doğrulama mobil bir cihaz tarafından desteklenen bir web tarayıcısı kullanılarak sağlanır:

• Android: Google Chrome.
• iOS: sürüm 9.0 veya sonrası.

Mobil cihazınız yukarıdaki gereksinimlere uygun değilse OpenID Connect sağlayıcısı tarafında bir mobil istemcide yeniden kimlik doğrulaması yapmanız gerekebilir. Bir dahaki sefere oturum açtığınızda zorlanmış kimlik doğrulamayı başlatmak için mobil istemcide Oturumu kapat komutunu yürütün.

Ayrıca bkz.:

• OpenID Connect işlemleri
• default.vrd dosyası

6.2.10.6. JWT kimlik doğrulaması

Belirteç, uygulamada bir kullanıcının veya ayrı bir oturumun kimliğini doğrulamak için kullanılan bir araçtır. JSON Web Token (JWT), JSON formatına dayalı olarak erişim belirteci oluşturma standardıdır. JWT, RFC 7519 standardında tanımlanmıştır (https://datatracker.ietf.org/doc/html/rfc7519). JWT, istemci/sunucu uygulamalarında kullanıcı kimlik doğrulaması için kullanılır.

JWT kimlik doğrulaması, yalnızca web sunucusunda yayınlanan Infobase'lerde kullanılabilir. JWT'yi belirtmek için istemci uygulama başlangıç komut satırında AccessToken komutunu kullanın.

Yayınlanan bir Infobase belirli bir şekilde yapılandırılmalıdır. Bir yayını ayarlamak için default.vrd dosyasını kullanın.

Ayrıca bkz.:

• JWT işlem tanımı
• default.vrd dosyası

6.2.10.7. İki faktörlü kimlik doğrulama

6.2.10.7.1. Genel bilgiler

Platform, kullanıcı kimlik doğrulamasını bağımsız olarak gerçekleştirebilir veya güvendiği başka bir kaynak (işletim sistemi veya OpenID sağlayıcısı) tarafından gerçekleştirilen kimlik doğrulama sonuçlarını kullanabilir. Her durumda, kullanıcı bir kullanıcı adı ve bir parola girer. Doğru kullanıcı adı/parola çifti girilirse platform kullanıcının tanımlandığını varsayar ve uygulamaya erişim izni verir.

Bu geleneksel şema basit ve kullanışlı olmakla birlikte ciddi bir dezavantajı da vardır. Parolayı hatırlamanız gerektiğinden parola kısa ve basit olmalıdır. Ancak, böyle bir parolanın kırılması kolaydır. Kırılması zor bir parola için parola uzun ve zor olmalıdır. Fakat böyle bir parolayı da hatırlamak kolay değildir. Dolayısıyla, uygulamada bu durum, insanların farklı kaynaklar için aynı basit parolaları kullanmasıyla sonuçlanıyor.

İki faktörlü kimlik doğrulama, bir yandan bilgisayar korsanları için kullanıcı verilerine erişimi zorlaştırmanızı sağlayan bir yöntem, diğer yandan da klasik parola korumasının dezavantajlarını bir ölçüde azaltan bir çözümdür.

İki faktörlü kimlik doğrulama, kullanıcının üç olası kimlik doğrulama verisi türünden ikisine sahip olmasını gerektirir:

• Bildikleri ve hatırladıkları bir şey. Bu kullanıcı adı ve parola oluyor.
• Sahip oldukları bir şey. Bu bir kullanıcı cep telefonu veya e‑postası olabilir.
• Kendilerine özgü bir şey. Bu, parmak izi, portre veya iris deseni gibi kullanıcının fiziksel bir özelliği olabilir.

İki faktörlü kimlik doğrulamanın amacı, kullanıcının uygulama çözümüne erişmek için kimliğini iki kez onaylamak zorunda olmasıdır. Üstelik bunu farklı şekillerde yapması gerekir. Örneğin, kullanıcı adı ve şifrenin girilmesi ilk kimlik doğrulama faktörü olurken, cep telefonuna gönderilen kodun girilmesi ikinci kimlik doğrulama faktörü olacaktır.

İlk kimlik doğrulama faktörünün doğrulanması 1C:Enterprise platformunun kendisi tarafından gerçekleştirilir ve ikinci kimlik doğrulama faktörünü işlemek için ikinci faktör sağlayıcısı olarak adlandırılan bir üçüncü taraf hizmeti kullanılır.

İkinci faktör sağlayıcısı (bu bölümde "sağlayıcı" terimi kullanılabilir), belirli işlemleri gerçekleştirmek için API sağlayan bir HTTP servisidir. Mesajları iletmek ve kimlik doğrulaması yapmak için bir dizi HTTP servisi Infobase'de uygulanıyorsa bir 1C:Enterprise Infobase'i ikinci faktör sağlayıcısı olarak çalışabilir. SMS veya e-posta mesajlarını gönderen, bir üçüncü taraf hizmet olabilir, ikinci kimlik doğrulama faktörünün kodlarını oluşturan bir hizmet olabilir veya kendi mobil uygulaması aracılığıyla kullanıcıyla etkileşime giren bir hizmet olabilir, vb. Önemli olan tek şey, sağlayıcıya HTTP istekleri aracılığıyla erişilebilmesidir.

İki faktörlü kimlik doğrulamayı yalnızca 1C:Enterprise araçlarıyla (standart kimlik doğrulama) herhangi bir infobase modunda ve herhangi bir istemci uygulamasında kimlik doğrulama için kullanabilirsiniz.

Ayrıca bkz.:

• 1C:Enterprise doğrulaması

6.2.10.7.2. İkinci faktörü kullanmak için seçenekler

Bu şekilde, standart 1C:Enterprise kimlik doğrulaması (ilk faktör) aşağıdaki gibidir:

1. Kullanıcı istemci uygulamayı başlatır. İstemci uygulama kullanıcıdan ilk kimlik doğrulama faktörünü ister: kullanıcı adı ve parola. Kullanıcı, kullanıcı adını ve parolasını girer ve istemci uygulama bunları sunucuya gönderir.
2. Sunucu, kullanıcı adı ve parolanın doğruluğunu kontrol eder.
3. Girilen veriler doğruysa sunucu, kullanıcının uygulamayı kullanmak için yalnızca bir tane kimlik doğrulama faktörüne ihtiyacı olduğunu kontrol eder. İkinci faktör kullanılmıyorsa kullanıcının tam olarak tanımlandığı ve işlemlere başlayabileceği varsayılır. Bu yaygın bir kimlik doğrulama senaryosudur.

Kullanıcı için iki faktörlü kimlik doğrulama ayarlanmışsa ilk iki adım daha önce olduğu gibi gerçekleştirilir (kullanıcı adı ve parolanın girilmesi ve bu verilerin 1C:Enterprise sunucusu tarafından kontrol edilmesi).

İkinci faktörün kullanımı iki biçimde gerçekleştirilebilir:

1. 1C:Enterprise sunucusunun kendisi ikinci bir faktör oluşturur ve kullanıcının bu faktörün değerini doğru girip girmediğini kontrol eder. Sağlayıcı yalnızca aktarma fonksiyonunu yerine getirir ve ikinci faktör değerini kullanıcıya iletir. Bu durumda, hem 1C:Enterprise sunucusu hem de kullanıcı ikinci faktör değerini iletmek için kullanılan kanalı bilir.

   Prosedür aşağıdaki gibidir:

   • 1C:Enterprise sunucusu, kullanıcının ikinci bir kimlik doğrulama faktörü belirtmesi gerektiğini uygulamaya bildirir.
   • Uygulama ikinci faktör giriş formunu görüntüler.
   • 1C:Enterprise sunucusu ikinci faktörün değerini (örneğin, belirli bir sayı) oluşturur ve kullanıcıya gönderir. Kullanıcı, uygulama tarafından açılan forrmda bu değeri girmelidir. İkinci faktör değeri kullanıcıya e-posta veya SMS aracılığıyla gönderilebilir.
   • Kullanıcı ikinci faktör verisini alır ve uygulama tarafından açılan iletişim kutusunda girer. Uygulama, ikinci faktör verisini 1C:Enterprise sunucusuna gönderir.
   • 1C:Enterprise sunucusu, girilen verinin sunucu tarafından oluşturulan ve kullanıcıya gönderilen veri ile eşleştiğini doğrular.
   • Uygulama tarafından iletilen ikinci faktör değeri ile 1C:Enterprise sunucusu tarafından oluşturulan değer eşleşirse kullanıcı tanımlanır ve uygulamaya erişim izni verilir.
2. 1C:Enterprise sunucusu, kullanıcı tarafından ikinci faktörün uygulanmasının sonucunu 1C:Enterprise sunucusuna gönderen bir üçüncü taraf hizmet kullanır. Bu durumda, 1C:Enterprise sunucusu, kullanılan ikinci faktörün türü hakkında hiçbir bilgiye sahip değildir. İkinci faktörü iletme yöntemi de seçilen ikinci faktör sağlayıcısı tarafından belirlenir. 1C:Enterprise sunucusu yalnızca, ikinci kimlik doğrulama faktörünü kullanma gereksinimine yanıt olarak ikinci faktörün başarılı bir şekilde uygulanıp uygulanmadığını bildiren güvenilir bir hizmet olduğu bilgisine sahiptir.

   Prosedür aşağıdaki gibidir:

   • 1C:Enterprise sunucusu, kullanıcının ikinci faktörü sağlayıcı tarafında doğrulaması gerektiğini istemci uygulamaya bildirir.
   • İstemci uygulama, kullanıcının ikinci faktör sağlayıcısı tarafından kimliği doğrulandıktan sonra belirli bir işlemi gerçekleştirmesi gereken formu kullanıcıya gösterir.
   • Sunucu, kullanıcının kimliğini doğrulamak için sağlayıcıya bir HTTP isteği gönderir.
   • Sağlayıcı, kimlik doğrulama işlemine başlar. Kimlik doğrulama yöntemi sağlayıcının takdirindedir.
   • Kimlik doğrulama işlemi tamamlandıktan sonra, kullanıcı bunu istemci uygulamaya bildirir.
   • İstemci uygulama bu bilgileri, ikinci faktör sağlayıcısından kimlik doğrulama sonuçlarını isteyen 1C:Enterprise sunucusuna iletir.
   • Sağlayıcı, kimlik doğrulama sonuçlarını sunucuya bildirir. Kimlik doğrulama başarılıysa kullanıcı tanımlanmış sayılır ve kullanıcıya uygulamaya erişim yetkisi verilir.

Bu bölümde incelenen her yöntem 1C:Enterprise uygulaması tarafından belirli bir şekilde desteklenir. İkinci kimlik doğrulama faktörü ayarı, sonraki bölümde incelenmiştir.

6.2.10.7.3. İkinci faktör ayarı

1C:Enterprise'da ikinci faktörün kullanımının ayarlanması birkaç bölüme ayrılmıştır:

• Sağlayıcılara gönderilen istek şablonlarının yapılandırılması.
• Bir istek şablonunun bir Infobase kullanıcısına bağlanması.
• Parametrelendirme isteği.

Her bir bölümü daha ayrıntılı inceleyelim.

Sağlayıcıya gönderilecek HTTP isteğini tanımlamak için SecondAuthenticationFactorSettingTemplate nesnesi kullanılır. Şablon parametreleri ayarlanırken ikinci kimlik doğrulama faktörü seçeneklerinden biri seçilir. İkinci kimlik doğrulama faktörünün ilk seçeneğinin uygulanması gerekiyorsa (1C:Enterprise sunucusu ikinci faktör değerini oluşturur, gönderir ve kontrol eder) AuthenticationHTTPRequest ve AuthenticationHTTPRequestMethod özellikleri kullanılır. İlk özellik HTTP isteğinin açıklamasını içerir (HTTPRequest türünde bir nesne) ve ikinci parametre sağlayıcıya ikinci kimlik doğrulama faktörünü istemek için hangi HTTP yönteminin kullanılacağını belirtmenizi sağlar.

İkinci kimlik doğrulama seçeneğinin uygulanması gerekiyorsa (1C:Enterprise sunucusu yalnızca ikinci faktör sağlayıcısında kimlik doğrulamayı başlatır ve sonucunu alır) yukarıda incelenen parametreler korunur. Bu parametreler ikinci kimlik doğrulama faktörü için kullanılır. Kimlik doğrulama sonucunu kontrol etmek için aşağıdaki ek özellikleri kullanın: AuthenticationResultVerificationHTTPRequest ve AuthenticationResultVerificationHTTPRequestMethod.

Her şablonun kendi adı (aynı adlı özellik) vardır, bu da başka işlemler gerçekleştirirken şablonu tanımlamanızı sağlar.

Herhangi bir özelliği ayarlamak için bir HTTP isteği oluştururken aşağıdaki özellikleri göz önünde bulundurun:

1. HTTP yöntemi bir dize olarak belirtilir. Bunun nedeni HTTP spesifikasyonunun özel eylemlerin (yöntemlerin) kullanımına izin vermesidir.
2. İstek metni parametreler içerebilir. Parametre "&" karakteriyle başlayan bir metindir. Örneğin, &user_name parametresiyle bir kullanıcı adını belirtebilirsiniz. Bu parametreler, isteğin gönderilme zamanında gerçek değerleriyle değiştirilecektir (aşağıda incelenecektir). Bu kararın nedeni, farklı kullanıcılar için ikinci kimlik doğrulama faktörünün HTTP isteklerinin neredeyse aynı olacağı varsayımıdır. Farklılıklar yalnızca belirli bir kullanıcıya özgü bazı bilgilerde görülecektir. Örneğin, ikinci faktör koduyla metin mesajı göndermek için koşullu bir istek şu şekilde görünür: . İsteği gönderirken, &phone_number parametresi kullanıcının asıl telefon numarası ile değiştirilecektir.

   Platform, platform tarafından oluşturulan ikinci faktörün değerini içeren önceden tanımlanmış &secret değişkenini sağlar.

Bütün bu bilgilere baktıktan sonra, ilk seçeneğe göre ikinci faktörle çalışmak için bir şablon oluşturma örneğine bakalım (platform ikinci faktörü oluşturur, gönderir, girdi ve doğrulama sağlar):

Request = New HTTPRequest;
Request.Resource Address = "&addr";
Request: SetBodyFromString ("& Gizli değeri girin. Bu değeri kimseye söylemeyin!", "Utf-8");
Provider = SecondAuthenticationFactorSettingsTemplates.CreateTemplate();
Provider.AuthenticationHTTPRequest = Request;
Provider.AuthenticationHTTPRequestMethod = "POST";
Provider.Name = "Request - response";
Provider.Record();

İlk üç dize, platform tarafından kullanılacak HTTP isteğini oluşturur. Kalan dizeler, POST yöntemini kullanarak isteği gönderecek ve İstek ‑yanıtı adına sahip olacak ikinci faktör sağlayıcısının şablonunu oluşturur.

İkinci seçeneğe göre kullanılan ikinci faktör sağlayıcısı için bir şablon oluşturulması gerekiyorsa (tüm işlemler sağlayıcı tarafından gerçekleştirilir, platform yalnızca işlem başlangıcını başlatır ve kimlik doğrulama sonucunu talep eder), yukarıdaki örnek şu şekilde değiştirilmelidir:

1. Kimlik doğrulama isteği, kullanılan sağlayıcının gerekliliklerine uyar.
2. Kimlik doğrulama sonuçlarını kontrol etmek için istek oluşturulur ve şablonda ayarlanır. Bu istek, kullanıcının sağlayıcıda kimlik doğrulamasını geçtiğini istemci uygulamaya "bildirmesinden" sonra yapılacaktır.

Sağlayıcılar için bir veya birkaç şablon kaydettikten sonra, şablonlardan birini kullanıcıya atayabilirsiniz. Bir kullanıcıya birden fazla şablon atayabileceğinizi ve bunların nasıl işleneceğini belirleyebileceğinizi unutmayın.

Kullanıcı ayarlarını yapmak için InfobaseUser nesnesinin iki özelliği kullanılır:

• SecondAuthenticationFactorSetting. Burada SecondAuthenticationFactorSetting türünde bir dizi nesne atamanız gerekir.
• SecondAuthenticationFactorSettingsProcessing. Birden fazla ikinci faktör sağlayıcısı belirtilirse ve ilk (geçiş sırasına göre) sağlayıcı bir hata döndürürse platformun ne yapacağını açıklar.

Yukarıdaki özellikler belirlendikten sonra, Infobase kullanıcısını tanımlayan nesne kaydedilecektir.

Göz önünde bulundurmamız gereken son nokta, platformun HTTP isteklerinde değişkenlerin yerine geçecek değerleri nereden alacağıdır. Bunun için SecondAuthenticationFactorSetting nesnesini inceleyelim. Bu nesene iki alan içerir:

• SettingTemplateName. Bu alanda, sağlayıcı şablonu ayarlanırken Name özelliğinde belirtilen ikinci faktör sağlayıcı ayarının şablon adını belirtin.
• Parameters. Bu özelliğe bir eşleşme atamalısınız. Eşleşme, ikinci faktör sağlayıcının ayar şablonunda bulunan parametreler kadar öğe içermelidir (&secret parametresi hariç). Bir parametre adı ("&" karakteri olmadan) bir eşleme öğesi anahtarı olarak işlev görür ve bir değişken değeri, bir değerdir.

Artık Infobase kullanıcısına Infobase'de oturum açarken iki faktörlü kimlik doğrulamanın gerekli olduğunu belirtmek için ihtiyacımız olan tüm bilgilere sahibiz.

ProviderParameters = New Map;
ProviderParameters.Insert("addr", "http://example.com/resource");
UserSetting = New SecondAuthenticationFactorSetting;
UserSetting.SettingTemplateName = "Question - answer";
UserSetting.Parameters = ProviderParameters;

UserSettings = New Array;
UserSettings.Add(UserSetting);

User = InfobaseUsers.FindByName("Seller");
User.SecondAuthenticationFactorSettings = UserSettings;
User.SecondAuthenticationFactorSettingsProcessing = SecondAuthenticationFactorSettingsProcessingType.UseNextIfFailed;
User.Record();

Platform, aşağıdaki özelliklerde parametre adlarını gerçek değerlerle değiştirecektir:

• HTTPRequest.ResourceAddress özelliği.
• HTTPRequest.Headers özelliği.
• HTTPRequest nesnesi istek gövdesi. İstek gövdesini belirtme yöntemi, değiştirme işlemini etkilemez.
• SecondAuthenticationFactorSettingTemplate.AuthenticationHTTPRequestMethod özelliği.
• SecondAuthenticationFactorSettingTemplate.AuthenticationResultVerificationHTTPRequestMethod özelliği.

Kullanıcı için seçilen ikinci faktör sağlayıcısı "bozuk" ise kullanıcının Infobase'e erişemeyeceğini unutmayın. Bu durumda, "bozuk" terimi, sağlayıcının görevini tamamlamasına izin vermeyen herhangi bir olay anlamına gelir: sunucudan sağlayıcıya erişim için İnternet bağlantısı olmaması, sağlayıcıdan kullanıcıya erişim için İnternet bağlantısı olmaması, sağlayıcı tarafında bir hata vb.

Ayrıca, ikinci faktör için üçüncü taraf bir sağlayıcı kullanmayı planlıyorsanız bu sağlayıcının hizmetlerinin ücretli olabileceğini ve sağlayıcının 1C:Enterprise sisteminin dışında kalan ve bu belgede ele alınmayan ek koşullar ve kısıtlamalar getirebileceğini dikkate almanız gerekir.

6.2.10.7.4. OpenID Kimlik Doğrulaması ve iki faktörlü kimlik doğrulama

1C:Enterprise, OpenID protokolünü kullanarak kimlik doğrulamayı destekler. Bilgi sistemi OpenID kimlik doğrulamasını kullanıyorsa ikinci faktör OpenID sağlayıcısından istenecektir. Bu durum, OpenID sağlayıcısı olarak bir 1C:Enterprise Infobase'i belirtildiğinde de geçerlidir. Başka bir deyişle, OpenID sağlayıcısı olan Infobase'de iki faktörlü kimlik doğrulama yapılandırılmalıdır.

6.2.10.8. Mobil istemci üzerinden oturum açmak için biyometri kullanımı

Biyometrik kimlik doğrulamayı destekleyen (parmak izi sensörü, yüz veya iris tarayıcısı vb. olan) cihazlar söz konusu olduğunda, mobil istemci Infobase ayarında ve kimlik doğrulama (mobil cihazda) iletişim kutularında Biyometri kullan onay kutusu kullanılabilir. Bu onay kutusu işaretlendiğinde aşağıdaki mekanizma aktive edilir:

• İlk kez oturum açtığınızda, OpenID ve web sunucusu kullanarak Infobase ve kimlik doğrulama için girdiğiniz kullanıcı adları ve parolalar güvenli bir depoda saklanır.
• Bir sonraki oturum açışınızda aşağıdaki mantık uygulanır:
  • İlk olarak, kimlik doğrulamanın o anda gerekli olmadığını veya OpenID sağlayıcısı tarafından bildirilen ilgili kimlik doğrulama verilerinin bulunduğunu doğrulamak için güvenli bir depoda bulunan veriler kullanılmadan oturum açma girişiminde bulunulur. Bir mobil cihaz ilgili kimlik doğrulama verilerini saklıyorsa kimlik doğrulama amacıyla biyometrik veri sağlama talebi yalnızca kimlik doğrulama verisi kullanım süresi sona erdiğinde yapılır.
  • Önceki adım başarısız olursa kullanıcıdan bir mobil işletim sistemi arayüzünü kullanarak biyometrik kimlik doğrulaması yapması istenir. Mobil cihaz kullanıcı ayarlarında belirtilen kimlik doğrulama türü istenir.
  • Biyometrik kimlik doğrulama bir kullanıcı tarafından devre dışı bırakılırsa kullanıcı adı ve parola içeren standart kimlik doğrulama iletişim kutusu görüntülenir.
  • Biyometrik veriler mobil cihaz tarafından kabul edilirse önceki başarılı kimlik doğrulama sırasında kaydedilen veriler güvenli depolama alanından alınır. Söz konusu veriler kimlik doğrulama amacıyla kullanılır.
  • Bu veriler bir mobil cihaz tarafından kabul edilmezse önceki başarılı kimlik doğrulama sırasında kaydedilen veriler güvenli depolama alanından silinir. Ardından, kullanıcı adı ve parola içeren standart kimlik doğrulama iletişim kutusu görüntülenir.
• Kimlik doğrulama OpenID Connect aracılığıyla yapılırsa biyometrik veri kullanılmaz, çünkü bu senaryoda kimlik doğrulamayı gerçekleştirmek için OpenID Connect sağlayıcısının korumalı bir web sayfası kullanılır. Bu sayfada, bu sağlayıcı için önceden kaydedilmiş kullanıcı adı ve şifre otomatik olarak eklenemez. Ayrıca OpenID Connect, kullanıcı adı ve parola girmek için herhangi bir süre sınırı olmaksızın bu cihazda sürekli kimlik doğrulamayı destekler.

  Mobil cihazınız OpenID Connect aracılığıyla kimlik doğrulamayı destekliyorsa bu yöntem kimlik doğrulama amacıyla kullanılır. OpenID Connect aracılığıyla kimlik doğrulama devre dışı bırakıldığında, biyometrik verileri kullanarak hızlı bir şekilde oturum açabilirsiniz. OpenID Connect aracılığıyla tekrarlı şekilde kimlik doğrulaması yapmak için önce bir oturum açma girişiminin başarısız olması gerekir.

<< Prev   Next >>