Playtech

האתגר

Playtech נדרשה לאימות שעובד natively בתוך מוצר Avalonia, תוך תמיכה בבדיקות זהות ברמת ודאות גבוהה — כולל ביומטריה ו-OTP — במסופי קופה ובמכשירי מובייל.

אינטגרציית SDK: הטמעת SDK Android natively ב-stack של .NET Avalonia בלי לפצל את חוויית הפיתוח.

ביומטריה מרובת ספקים: תמיכה באימות פנים דרך CAF ו-Unico עם UX עקבי ונתיבי fallback.

Handoff omnichannel: גשר מאובטח של סשן ממסוף לטלפון — המשך אימות במובייל בלי להתחיל מחדש.

ביצועים native: זרימות זיהוי פנים מהירות, יציבות ואמינות על חומרת Android.

הפתרון

מובלרס סיפקה SDK Android native ואפליקציות אימות נלוות — אימות מאובטח, סקיילבילי וביצועים גבוהים בתוך מערכת Avalonia של Playtech.

הפתרון משלב התחברות עם OTP, אימות פנים דו-ספקי, הרשמה פנימית והעברת סשן cross-device — חוויית omnichannel חלקה ממסוף קופה להשלמה במובייל.

Playtech יכולה כעת להציע חוויית Android native לזרימות ביומטריות קריטיות, תוך שמירה על ארכיטקטורת אימות אחידה בפלטפורמה.

מדריך אינטגרציה טכני

גבול הראיות

המידע הציבורי על הפרויקט מאשר את גבולות המוצר: SDK נייטיב ל-Android שולב במוצר .NET Avalonia של Playtech; הפתרון כלל OTP, אימות פנים באמצעות CAF ו-Unico, העברת סשן מבוססת Web ממסוף למובייל ושתי אפליקציות Android נייטיב נלוות.

מבנה ה-AAR/JAR, מטא-דאטה של ה-binding, שמות ה-API בפועל, גרסאות התלויות, גרף Gradle, רמות Android API, מטריצת המכשירים, פורמט הטוקנים, תצורת ההצפנה וטלמטריית הייצור אינם ציבוריים. לכן החומר להלן הוא דפוס יישום מייצג, ולא קוד המקור של Playtech או תיאור של התצורה החסויה שלה.

ארכיטקטורת ייחוס

┌──────────────────────── תהליך .NET / Avalonia ──────────────────────────┐
│ Avalonia UI → IAuthenticationSdk → Android adapter                     │
│                                      │ callbacks / Task completion      │
└──────────────────────────────────────┼───────────────────────────────────┘
                                       │ generated C# binding (JNI)
┌──────────────────────── גבול Android runtime ───────────────────────────┐
│ Native authentication SDK → OTP / registration / biometric coordinator│
│          │                         │                                    │
│          │ Android Activity/Intent │ HTTPS provider/backend calls       │
│          ▼                         ▼                                    │
│ Companion app A / Companion app B  CAF / Unico / Playtech services     │
└─────────────────────────────────────────────────────────────────────────┘

מסוף קופה → URL למסירה / סשן חד-פעמי → מכשיר המובייל של המשתמש
           → אימות באפליקציה הנייטיב → תוצאה מהבקאנד → המסוף

שכבת Avalonia צריכה להיות תלויה בממשק C# קטן ולא בטיפוסי Java/Kotlin. את הקוד הייחודי ל-Android משאירים ביעד Android, משתמשים ב-binding של .NET for Android בגבול JNI ומחזירים לשכבה המשותפת תוצאות מנורמלות. האפליקציות הנלוות נמצאות מחוץ לתהליך Avalonia; deep link, ‏App Link מאומת או Android Intent מפורש יכולים להפעיל אותן אם חוזה הייצור המאושר דורש מעבר בין אפליקציות.

אריזה וצינור הבנייה

פורמט ההפצה בפועל של Playtech אינו ציבורי. שחזור מקובל משתמש ב-Android Archive (.aar) ובספריית binding של .NET for Android. לפי תיעוד Microsoft, ספריית binding מייצרת מעטפות C# ל-API של Java ומעבירה משאבי Android ותלויות נייטיב לבניית האפליקציה.

פרויקט binding מינימלי:

<!-- ReferenceAuthSdk.Binding/ReferenceAuthSdk.Binding.csproj -->
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net9.0-android</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <AndroidLibrary Include="Jars/reference-auth-sdk.aar" />
    <!-- תלויות שלא נקראות ישירות מ-C# -->
    <AndroidLibrary Include="Jars/provider-runtime.aar" Bind="false" />
  </ItemGroup>
</Project>

צריכה מיעד Android של Avalonia:

<!-- MyProduct.Android/MyProduct.Android.csproj -->
<ItemGroup>
  <ProjectReference Include="../ReferenceAuthSdk.Binding/ReferenceAuthSdk.Binding.csproj" />
  <!-- לחלופין: PackageReference לחבילת binding מאושרת -->
</ItemGroup>

אם ה-SDK מפורסם ב-Maven והבנייה משתמשת ב-.NET 9 ומעלה, אפשר להשתמש ב-AndroidMavenLibrary. אם AAR מכיל קובצי .so, יש לוודא שכל ABI נתמך קיים ולהוסיף ספריות חסרות כ-AndroidNativeLibrary; אחרת האפליקציה עלולה להיכשל עם UnsatisfiedLinkError. אין להוסיף את אותה תלות גם דרך Gradle, משום שכפילויות מחלקות עלולות לשבור את D8/R8.

פקודות בנייה לדוגמה:

dotnet workload install android
dotnet restore MyProduct.sln
dotnet build ReferenceAuthSdk.Binding/ReferenceAuthSdk.Binding.csproj -c Release
dotnet publish MyProduct.Android/MyProduct.Android.csproj -c Release -f net9.0-android
adb install -r MyProduct.Android/bin/Release/net9.0-android/publish/*.apk
adb logcat

את גרסאות .NET, ‏Avalonia, ‏Android Gradle Plugin, ‏Java, ספקי הביומטריה ו-target SDK יש לנעול לפי מניפסט השחרור המאושר של Playtech. ראו את מדריך ה-binding של .NET for Android.

Interop, מחזור חיים ו-threading

לשכבת Avalonia המשותפת חושפים חוזה שאינו תלוי פלטפורמה:

public interface IAuthenticationSdk
{
    Task InitializeAsync(AuthSdkOptions options, CancellationToken ct);
    Task<AuthResult> AuthenticateAsync(AuthRequest request, CancellationToken ct);
}

public sealed record AuthRequest(string CorrelationId, AuthMethod Method);
public sealed record AuthResult(bool Succeeded, string? ErrorCode, string? SessionId);
public enum AuthMethod { PasswordOtp, FacialVerification, Registration }

ה-adapter של Android עוטף טיפוסים שנוצרו ב-binding, מתרגם callback פעם אחת ואינו מחזיק Activity ב-singleton:

public sealed class AndroidAuthenticationSdk : Java.Lang.Object,
    IAuthenticationSdk, IReferenceAuthCallback
{
    readonly Func<Android.App.Activity> currentActivity;

    public AndroidAuthenticationSdk(Func<Android.App.Activity> currentActivity) =>
        this.currentActivity = currentActivity;

    public async Task<AuthResult> AuthenticateAsync(AuthRequest request, CancellationToken ct)
    {
        var completion = new TaskCompletionSource<AuthResult>(
            TaskCreationOptions.RunContinuationsAsynchronously);
        using var registration = ct.Register(() => completion.TrySetCanceled(ct));
        pending[request.CorrelationId] = completion;

        currentActivity().RunOnUiThread(() =>
            ReferenceAuth.Client.Start(currentActivity(), request.CorrelationId, this));

        try { return await completion.Task.ConfigureAwait(false); }
        finally { pending.Remove(request.CorrelationId); }
    }

    public void OnSuccess(string correlationId, string sessionId) =>
        pending.Remove(correlationId, out var tcs)
            ? tcs.TrySetResult(new(true, null, sessionId))
            : _ = false;

    public void OnError(string correlationId, string code) =>
        pending.Remove(correlationId, out var tcs)
            ? tcs.TrySetResult(new(false, code, null))
            : _ = false;
}

זהו מבנה ייחוס ולא קוד drop-in: שמות ה-callback ומחזור החיים תלויים ב-binding שנוצר. יש להחזיק listener של Java כל עוד הפעולה פעילה, לנתק אותו בסיום, להעביר פעולות UI/מצלמה ל-main thread של Android ולהחזיר את מצב Avalonia ל-synchronization context המתאים.

יש לרשת מ-AvaloniaMainActivity, לקרוא לכל מימוש base ולהעביר רק אירועים שה-SDK דורש:

protected override void OnCreate(Android.OS.Bundle? state)
{
    base.OnCreate(state);
    AndroidSdkHost.Attach(this, state);
}

protected override void OnNewIntent(Android.Content.Intent? intent)
{
    base.OnNewIntent(intent);
    if (intent is not null) AndroidSdkHost.HandleIntent(intent);
}

protected override void OnDestroy()
{
    AndroidSdkHost.Detach(this);
    base.OnDestroy();
}

Android עשוי ליצור מחדש Activity לאחר סיבוב, לחץ זיכרון או Intent חוזר. מצב מתמשך נשמר מחוץ ל-Activity ורק מזהה correlation/session אטום נשמר; יש לדחות callbacks כפולים ולעולם לא להחזיק Activity ישן. Avalonia חושפת callbacks להרשאות ולתוצאות Activity דרך AvaloniaActivity; ראו Android activity API והנחיות activation lifecycle.

למעבר לאפליקציה נלווית מומלץ App Link מאומת או Intent מפורש עם מזהה חד-פעמי וקצר-חיים:

var intent = new Android.Content.Intent(
    Android.Content.Intent.ActionView,
    Android.Net.Uri.Parse(handoffUrl));
intent.AddFlags(Android.Content.ActivityFlags.SingleTop);
activity.StartActivity(intent);

אין לשים ב-URI תמונות ביומטריות, פרטי גישה, access tokens או מסמכי זהות. יש לקשור את מזהה ההעברה בצד השרת לסשן היוזם ולאפשר שימוש יחיד.

משטח API וטיפול בשגיאות

API יציב ל-Avalonia צריך לכלול:

• אתחול חד-פעמי עם סביבה, tenant, שפה ותצורה ציבורית שאינה סוד.
• פעולות credentials/OTP, אימות פנים, הרשמה, ביטול ושחזור מצב.
• callbacks מובנים כגון AwaitingOtp, ‏OpeningCompanionApp, ‏Capturing, ‏Submitting ו-Completed.
• קודי שגיאה יציבים ונפרדים לביטול, ולידציה, הרשאות, רשת, ספק, תצורה, timeout ושגיאה פנימית.
• Correlation ID לתמיכה ול-audit ללא חשיפת ביומטריה או סודות.

אין לפרש Result.Ok של Activity כהצלחת אימות. יש לאמת תוצאה חתומה או מאושרת-שרת דרך חוזה הבקאנד המאושר.

אסטרטגיית בדיקות מומלצת

• בדיקות binding: בניית AAR ב-Release, בדיקת API שנוצר, מיזוג משאבים, כללי R8/ProGuard, כל ABI וסגירת תלויות.
• בדיקות חוזה: adapter מדומה לבדיקת אתחול, התקדמות, ביטול, timeout, callback כפול, שגיאת ספק ושחזור תהליך.
• בדיקות instrumentation: דחיית הרשאה, רקע/חזית, סיבוב, low-memory, חזרה מ-App Link, התאוששות offline ואפליקציה נלווית חסרה על מכשירים אמיתיים.
• בדיקות sandbox של הספק: tenants מאושרים של CAF ו-Unico ללא זהויות ייצור; בדיקת מיפוי תגובות ומדיניות fallback.
• בדיקות מקצה לקצה: התחלה במסוף, המשך במובייל, השלמה או נטישה ואימות שהתוצאה הקשורה לסשן מתקבלת פעם אחת.
• בדיקות אבטחה: הסתרת URI ולוגים, מניעת replay, אימות certificate/host, פקיעת סשן, מדיניות rooted/emulator, סריקת תלויות וחתימת Release.

תוצאות ומדדים מדידים

התוצאה הציבורית המאומתת היא איכותנית: Playtech קיבלה ארכיטקטורת אימות אחידה למסוף ולמובייל, זרימות ביומטריות נייטיב ל-Android, שני ספקים, שתי אפליקציות נלוות ובעלות מלאה על הקוד והארטיפקטים שנמסרו.

אין כיום מאגר ציבורי מאושר עם KPI מספריים מהפריסה. כדי לא להמציא טענות ביצועים או עסקים, מצב המדדים המבוקשים הוא:

• זמן אימות ביומטרי ממוצע: לא פורסם; חלון המדידה ומתודולוגיית האחוזונים אינם ציבוריים.
• דיוק זיהוי / true-positive rate: לא פורסם; אוכלוסיית הבדיקה והסף אינם ציבוריים.
• שיעורי false rejection ו-false acceptance: לא פורסמו; מערך התקיפות ונקודת העבודה אינם ציבוריים.
• מספר מסופים, מכשירי מובייל וסשנים מקבילים: לא פורסם.
• זמינות, MTBF, שיעור שגיאות בעומס וזמן התאוששות: לא פורסמו.
• שינוי בהמרה, זמן אימות/checkout, ירידת הונאה, עלות תמיכה ועלות תפעול: לא פורסמו.
• שביעות רצון, שיעור השלמה ו-baseline לפני/אחרי: לא פורסמו.
• תקופת המדידה, cohort, instrumentation, exclusions ומתודולוגיה סטטיסטית: לא פורסמו.

אין להציג נתוני שיווק או הסמכה כלליים של הספקים כתוצאות Playtech. ניתן להוסיף נתונים מספריים לאחר אישור baseline, תוצאות לאחר השקה, חלון מדידה, cohort ומתודולוגיה.

אבטחה ופרטיות

זרימת נתונים מאומתת ומייצגת

מסוף קופה
  └─ יוצר סשן בשרת + מזהה handoff חד-פעמי
       └─ אפליקציית mobile/Avalonia או אפליקציה נלווית
            ├─ קלט credentials / OTP
            ├─ צילום לזרימה ביומטרית מאושרת
            └─ שליחה לנקודת backend/provider מאושרת
                 ├─ CAF או Unico מבצעים את האימות שהוגדר
                 └─ התוצאה חוזרת לבקאנד
                      └─ המסוף מקבל סטטוס הקשור לסשן

העברת הסשן ממסוף למובייל והשימוש ב-CAF וב-Unico הם עובדות פרויקט מאומתות. לא פורסם אם תמונות מעובדות במכשיר, אצל Playtech או ישירות אצל הספק, מה נשמר, ומי משמש controller או processor.

בקרות שדורשות מפרט אבטחת ייצור

• גרסאות TLS/cipher suites, ‏certificate pinning ו-mTLS: לא פורסמו.
• אלגוריתמים במנוחה, הצפנת storage/database, הצפנה ברמת שדה, KMS/HSM, רוטציה ומשמורת מפתחות: לא פורסמו.
• מנפיק טוקן, אלגוריתם חתימה, scopes, ‏audience, משך חיים, refresh, קישור למכשיר/סשן, replay ו-revocation: לא פורסמו.
• תפקידי RBAC/ABAC ל-SDK, מסוף, אפליקציות נלוות, מפעילים, תמיכה ושירותי backend: לא פורסמו.
• תחולת GDPR/LGPD/ISO/PCI, תפקידי controller/processor, בסיס חוקי, residency, שמירה, מחיקה וזכויות נושא מידע: לא פורסמו לפריסה זו.
• סכמת audit, שמירת לוגים, ביקורת גישה, SIEM, תגובה לפריצה, הודעה ויעדי התאוששות: לא פורסמו.
• נוסח הסכמה, בדיקות גיל/זכאות, נגישות, opt-out מביומטריה ו-fallback לא ביומטרי: לא פורסמו.

ביישום ייחוס אין להעביר payload ביומטרי ללוגים או analytics של Avalonia; יש להשתמש ב-correlation ID אטום, בטוקנים קצרי-חיים ומוגבלי audience וב-handoff חד-פעמי שקשור לסשן ולהקשר מכשיר. לפני ייצור יש להגדיר הסכמה, שמירה, מחיקה, fallback, audit ותגובה לאירוע.

תיעוד ה-API הביומטרי של CAF מתאר את מודל הקלט והתוצאה הציבורי הנוכחי. Unico מפרסמת תיעוד אבטחה ותאימות. קישורים אלה נועדו לבדיקת ספק בלבד: תיעוד והסמכות נוכחיים אינם מוכיחים אילו גרסאות, בקרות או attestations שימשו בפריסת Playtech.

תאימות ודרישות

חוזה התאימות המדויק של Playtech אינו ציבורי:

• רמות Android API מינימלית ומומלצת: לא פורסמו.
• Target SDK, ‏compile SDK, גרסאות Java/.NET/Avalonia ותלות ב-Google Play Services: לא פורסמו.
• רזולוציית מצלמה, autofocus, יכולות liveness, ‏CPU/ABI, ‏RAM, אחסון וספי רשת: לא פורסמו.
• דרישות מינימום לשתי האפליקציות הנלוות ומחלקות מכשירים שאינן נתמכות: לא פורסמו.
• שמות המכשירים וגרסאות Android שנבדקו: לא פורסמו.

בדוגמת הייחוס יש לכוון לרמת Android שנדרשת בגרסת Avalonia ו-.NET for Android הנוכחית, ולהגדיר minSdk לפי הדרישה הגבוהה ביותר של ספקי הביומטריה. אין לנחש רמה נמוכה יותר: מניפסטי ה-AAR וה-release notes של הספק הם מקור האמת. יש לאשר arm64-v8a וכל ABI נוסף, הרשאות ותכונות מצלמה, חומרת מפתחות, טיפול ב-App Links ותמיכה במכשיר ללא Play Services.

מטריצת Release צריכה לכלול:

• API הישן ביותר שנתמך בפרופיל ה-RAM/CPU הנמוך ביותר שאושר.
• API המומלץ על חומרת המסוף והמובייל המרכזית.
• Target API החדש ביותר על לפחות מכשיר Google אחד ומכשיר של OEM מרכזי אחד.
• מצלמות קדמיות ברזולוציה המאושרת המינימלית, עם ובלי autofocus ובתנאי תאורה מייצגים.
• מכשירים ללא Google Play Services, אם הם מיועדים לתמיכה.
• רשת איטית, offline, מצלמה חסומה, אחסון וזיכרון נמוכים, process death, מדיניות rooted/emulator ואפליקציה נלווית חסרה.

במכשירים חלשים צפויים זמני מצלמה, עיבוד ומעברי Activity ארוכים יותר עד למדידה בפועל. יש לספק retry מוגבל, מצב התקדמות ברור, המשך בסיוע שרת ו-fallback מאושר של OTP/אימות ידני. אין להוריד בשקט ספי liveness או התאמה.

מגבלות אינטגרציה

• הקוד לעיל לא ייבנה עד להחלפת שמות ה-binding הגנריים ב-API שנוצר מה-SDK המאושר.
• יצירת binding עשויה לדרוש metadata fixes עבור overloads, ‏Java generics, ‏Kotlin suspend, ‏nullable annotations ושמות שעברו obfuscation.
• R8/ProGuard עלולים להסיר callbacks או מטרות reflection ללא consumer rules של הספק.
• Activity recreation, ‏process death, ‏Intents כפולים ו-callback מאוחר הם אירועי מחזור חיים רגילים.
• עבודה עם שני ספקי ביומטריה דורשת routing ו-fallback מפורשים; אין לעבור ספק ללא שמירת ההסכמה וה-audit.
• יש לאמת בנפרד רישוי SDK, זכויות הפצה, זמינות גאוגרפית, export controls ומדיניות החנות.
• אין לייחס ל-Playtech סף תאימות, בקרת אבטחה, הסמכה או KPI מהמדריך ללא אישור בכתב.