Συνεργάτης API Authorization Δοκιμές για AI API Πύλες μεταπωλητών

Ένας συνεργάτης API για πύλες μεταπωλητών πρέπει να υποθέσει ότι κάθε αναγνωριστικό αντικειμένου σε ένα αίτημα μπορεί να αντιγραφεί, να μαντέψει, να αναπαραχθεί ξανά, να καταγραφεί από άλλη ενοποίηση ή να περάσει από λάθος εργαλείο προσωπικού. Το βασικό πρόβλημα δεν είναι αν τα αναγνωριστικά πελατών είναι αδιαφανή. Το πρόβλημα είναι αν κάθε ενέργεια αποδεικνύει ότι ο καλών, ο λογαριασμός συνεργάτη, ο μισθωτής-στόχος, το αντικείμενο, η ιδιοκτησία και η κατάσταση έγκρισης ανήκουν μαζί.

Αυτό έχει μεγαλύτερη σημασία σε μια πύλη μεταπωλητή AI API επειδή το API συνήθως εκθέτει αντικείμενα επιπέδου ελέγχου υψηλής πρόσκρουσης: μεταγενέστερους πελάτες, εικονικά API κλειδιά, πορτοφόλια, προσαρμογές πίστωσης, εξαγωγές χρήσης, προορισμούς webhook, χρήστες προσωπικού και παγώματα έκτακτης ανάγκης. Ένας μεμονωμένος έλεγχος εξουσιοδότησης που λείπει μπορεί να επιτρέψει σε έναν πελάτη να διαβάσει τη χρήση ενός άλλου πελάτη, να αφήσει ένα διακριτικό προσωπικού να μεταφέρει πιστώσεις μεταξύ των ενοικιαστών ή να αφήσει ένα διακριτικό αυτοματισμού να ανακαλέσει ένα κλειδί που δεν θα έπρεπε ποτέ να δει.

Γεγονός: OWASP API Το Security 2023 παραθέτει το επίπεδο κατεστραμμένου αντικειμένου Authorization ως API1 και το επίπεδο ιδιότητας κατεστραμμένου αντικειμένου Authorization ως API3. Πρακτικά, οι έλεγχοι σε επίπεδο αντικειμένου απαντούν "μπορεί αυτός ο καλών να ενεργήσει σε αυτό το αντικείμενο;" ενώ οι έλεγχοι σε επίπεδο ιδιοκτησίας απαντούν "μπορεί αυτός ο καλών να ορίσει ή να διαβάσει αυτό το πεδίο;" Και τα δύο είναι πρώτης τάξεως ανησυχίες για το σχεδιασμό συνεργάτη API.

Καθορίστε το Authorization Συμβόλαιο πριν από τη σύνταξη δοκιμών

Authorization είναι χρήσιμες μόνο εάν δοκιμάζονται σε σχέση με μια ρητή σύμβαση πολιτικής. Ξεκινήστε με μια μήτρα που περιγράφει ποιος ηθοποιός μπορεί να κάνει ποια ενέργεια σε ποιον στόχο, υπό ποιες συνθήκες. Μην βασίζεστε σε ονόματα τελικών σημείων ή ρόλους διεπαφής χρήστη ως πολιτική.

Ένας χρήσιμος πίνακας έχει αυτές τις στήλες:

• Τύπος ηθοποιού: κάτοχος συνεργάτη, διαχειριστής συνεργάτη, φορέας χρηματοδότησης, χειριστής υποστήριξης, διακριτικό αυτοματισμού, διαχειριστής πελάτη, χρήστης μόνο για ανάγνωση.
• Λογαριασμός συνεργάτη: ο λογαριασμός μεταπωλητή ή εταιρείας στον οποίο ανήκει η μεταγενέστερη σχέση πελατών.
• Στόχευση μισθωτή: ο λογαριασμός μεταγενέστερου πελάτη που δημιουργείται, χρεώνεται, ελέγχεται, τίθεται σε αναστολή ή διαγράφεται.
• Τύπος αντικειμένου: πελάτης, εικονικό κλειδί, πορτοφόλι, καταχώριση λογιστικού βιβλίου, αναφορά χρήσης, τελικό σημείο σύνδεσης ιστού, χρήστης προσωπικού, προφίλ τιμολόγησης, αντιστοίχιση παρόχου.
• Ενέργεια: δημιουργία, ανάγνωση, λίστα, ενημέρωση, ανάκληση, συμπλήρωση, επιστροφή χρημάτων, εξαγωγή, πάγωμα, κατάργηση παγώματος.
• Νομισματική αρχή: εάν η ενέργεια αλλάζει το υπόλοιπο, το πιστωτικό όριο, το περιθώριο, την κατάσταση διακανονισμού, την κατάσταση τιμολογίου ή τα ανώτατα όρια δαπανών.
• Κατάσταση έγκρισης: εάν το αίτημα είναι προεγκεκριμένο, σε αναμονή έγκρισης, διπλής έγκρισης, ληγμένο ή μόνο έκτακτης ανάγκης.

Για παράδειγμα, μπορεί να επιτραπεί σε έναν χειριστή υποστήριξης να προβάλλει τα μεταδεδομένα του καλυμμένου κλειδιού ενός πελάτη και να παγώνει ένα κλειδί κατά τη διάρκεια ενός συμβάντος, αλλά να μην δημιουργεί πιστώσεις, να αλλάξει τον κατάλογο τιμολόγησης, να εξάγει δεδομένα πλήρους χρήσης ή να αποδεσμεύει το κλειδί χωρίς έγκριση. Ένας χρηματοοικονομικός φορέας μπορεί να δημιουργήσει μια προσαρμογή πίστωσης για έναν πελάτη που ανήκει στον ίδιο συνεργάτη, αλλά μόνο εντός ενός διαμορφωμένου ποσού και μόνο αφού υπάρχει ένα αρχείο έγκρισης.

Σύσταση: γράψτε τη μήτρα ως τεχνούργημα με έκδοση και, στη συνέχεια, κάντε κάθε αναφορά ονόματος δοκιμής εξουσιοδότησης μια σειρά ή κανόνα. Όταν αλλάζει μια πολιτική, η διαφορά θα πρέπει να δείχνει τόσο την αλλαγή συμβολαίου όσο και τη δοκιμαστική αλλαγή.

Χρήση Αναφορών αντικειμένων δεσμευμένου μισθωτή

Τα αδιαφανή αναγνωριστικά μειώνουν τον κίνδυνο απαρίθμησης, αλλά δεν αποδεικνύουν εξουσιοδότηση. Το αναγνωριστικό εικονικού κλειδιού, το αναγνωριστικό πορτοφολιού, το αναγνωριστικό καταχώρισης στο βιβλίο, το αναγνωριστικό εξαγωγής χρήσης ή το διακριτικό δρομέα πρέπει να επιλυθούν εντός του αναμενόμενου ορίου συνεργάτη και μισθωτή.

Ένα μοτίβο ασφαλούς αναζήτησης είναι:

resolve object where
  object.id = request.object_id
  and object.partner_id = actor.partner_id
  and object.customer_id = request.customer_id
  and actor has action_scope for object_type/action
  and object.state allows action

Το επικίνδυνο μοτίβο είναι:

object = find_by_id(request.object_id)
if actor.has_scope("keys:revoke"):
  revoke(object)

Η δεύτερη έκδοση εξουσιοδοτεί την κατοχή ενός πεδίου και όχι εξουσιοδότησης για τον στόχο. Αποτυγχάνει όταν ένα έγκυρο διακριτικό για τον Συνεργάτη Α υποβάλλει ένα αναγνωριστικό κλειδιού από τον Συνεργάτη Β ή όταν ένας χειριστής για τον Πελάτη Α υποβάλλει ένα αναγνωριστικό πορτοφολιού από τον Πελάτη Β.

Η δέσμευση ενοικιαστή θα πρέπει να καλύπτει περισσότερα από τα προφανή αντικείμενα. Συμπεριλάβετε διακριτικά δρομέα για αναφορές χρήσης, αναγνωριστικά εργασιών εξαγωγής, αναγνωριστικά τελικού σημείου webhook, αναγνωριστικά έγκρισης, κλειδιά αδυναμίας και αναγνωριστικά προσαρμογής καθολικού. Αυτά τα αντικείμενα συχνά αισθάνονται "εσωτερικά", γι' αυτό ακριβώς γίνονται αδύναμα σημεία.

Δημιουργία ελάχιστης συσκευής δοκιμής μεταξύ ενοικιαστών

Χρησιμοποιήστε ένα σκόπιμα μικρό εξάρτημα που καθιστά εύκολη την έκφραση της λανθασμένης πρόσβασης. Ο στόχος δεν είναι ο ευρύς όγκος δεδομένων. Ο στόχος είναι ο ξεκάθαρος διαχωρισμός.

Partner P1
  Staff: p1_owner, p1_support, p1_finance
  Token: p1_full_token, p1_support_token, p1_finance_token
  Customer C1A
    Key K1A
    Wallet W1A
    Usage cursor U1A
    Ledger entry L1A
  Customer C1B
    Key K1B
    Wallet W1B
    Usage cursor U1B
    Ledger entry L1B

Partner P2
  Staff: p2_owner
  Token: p2_full_token
  Customer C2A
    Key K2A
    Wallet W2A
    Usage cursor U2A
    Ledger entry L2A

Αυτό το πρόγραμμα σάς επιτρέπει να δοκιμάσετε δύο κατηγορίες αποτυχίας. Πρώτον, πρόσβαση μεταξύ πελατών του ίδιου συνεργάτη, όπου ένας καλών από το P1 προσπαθεί να αγγίξει το C1B ενώ ενεργεί στο C1A. Δεύτερον, πρόσβαση μεταξύ συνεργατών, όπου ένα διακριτικό P1 προσπαθεί να αγγίξει τα αντικείμενα του P2.

Σύσταση: εκτελέστε το ίδιο πρόγραμμα με τον δημόσιο συνεργάτη API και το backend της πύλης μεταπωλητή. Οι περιορισμοί διεπαφής χρήστη δεν προστατεύουν τους άμεσους API πελάτες, τις εργασίες στο παρασκήνιο, τα εργαλεία προγραμματισμού του προγράμματος περιήγησης ή τα παραβιασμένα διακριτικά ενοποίησης.

Επίπεδο αντικειμένου δοκιμής Authorization σε κάθε τελικό σημείο υψηλής πρόσκρουσης

Για κάθε τελικό σημείο που δέχεται ένα αναγνωριστικό αντικειμένου, δημιουργήστε τουλάχιστον ένα θετικό τεστ και αρκετές αρνητικές δοκιμές. Τα θετικά τεστ αποδεικνύουν ότι το εξάρτημα είναι έγκυρο. Οι αρνητικές δοκιμές αποδεικνύουν ότι το όριο ισχύει.

Δημιουργία και αναζήτηση πελατών

Η δημιουργία πελάτη συνήθως φαίνεται ακίνδυνη επειδή ο ενοικιαστής-στόχος δεν υπάρχει ακόμα. Εξακολουθεί να χρειάζεται εξουσιοδότηση επειδή ο καλών μπορεί να προσπαθήσει να δημιουργήσει πελάτες με διαφορετικό συνεργάτη, να εκχωρήσει ένα απαγορευμένο προφίλ τιμολόγησης ή να ορίσει εσωτερικά μεταδεδομένα.

Δοκιμαστικές περιπτώσεις:

• Ένας κάτοχος συνεργάτη μπορεί να δημιουργήσει έναν πελάτη υπό τον ίδιο συνεργάτη.
• Ένα διακριτικό αυτοματισμού με εύρος παροχής πελατών μπορεί να δημιουργήσει έναν πελάτη υπό τον ίδιο συνεργάτη.
• Ένα διακριτικό μόνο για υποστήριξη δεν μπορεί να δημιουργήσει πελάτη.
• Ένα διακριτικό P1 δεν μπορεί να δημιουργήσει πελάτη με partner_id=P2.
• Ένα διακριτικό σε επίπεδο πελάτη δεν μπορεί να αναφέρει τους αδελφούς πελάτες.

Δημιουργία, ανάκληση και περιστροφή κλειδιού

Οι βασικές ενέργειες του κύκλου ζωής έχουν μεγάλο αντίκτυπο επειδή παρέχουν πρόσβαση χρόνου εκτέλεσης και μπορούν να διακόψουν τον φόρτο εργασίας της παραγωγής. Τα επίπεδα ελέγχου παρόχου συνήθως εκθέτουν διαχειριστικά αντικείμενα, όπως έργα, χώρους εργασίας, λογαριασμούς υπηρεσιών, μέλη και κλειδιά API μέσω των API. Ένα επίπεδο πύλης ή μεταπωλητής θα πρέπει να αντιμετωπίζει τα δικά του εικονικά κλειδιά με την ίδια προσοχή.

Δοκιμαστικές περιπτώσεις:

• Ο αυτοματισμός P1 μπορεί να δημιουργήσει K1A μόνο για το C1A όταν το διακριτικό του περιλαμβάνει εύρος εγγραφής κλειδιού.
• Η υποστήριξη P1 δεν μπορεί να δημιουργήσει K1A εάν ο ρόλος υποστήριξης είναι μόνο για ανάγνωση για κλειδιά.
• Η υποστήριξη P1 μπορεί να παγώσει το K1A μόνο εάν το πάγωμα έκτακτης ανάγκης εμπίπτει στο πεδίο εφαρμογής.
• Η υποστήριξη P1 δεν μπορεί να ανακαλέσει το K1B όταν το πλαίσιο αιτήματος λέει C1A.
• Το πλήρες διακριτικό P1 δεν μπορεί να ανακαλέσει το K2A.
• Ο διαχειριστής πελάτη για το C1A δεν μπορεί να περιστρέψει, να αποκαλύψει ή να ανακαλέσει το K1B.

Για τις ομάδες που εφαρμόζουν το Partner API automation, η σημαντική δοκιμή δεν είναι απλώς «αυτό το διακριτικό έχει εγγραφή κλειδιού;» Είναι "αυτό το διακριτικό έχει key-write για αυτόν τον συνεργάτη, αυτόν τον πελάτη, αυτό το κλειδί, αυτήν την κατάσταση και αυτήν τη λειτουργία;"

Αναπλήρωση πιστώσεων και αλλαγές πορτοφολιού

Οι ενέργειες που συγκεντρώνουν χρήματα χρειάζονται αυστηρότερες δοκιμές από τις συνηθισμένες ενημερώσεις. Η ανανέωση πίστωσης μπορεί να είναι σωστή συντακτικά και να εξακολουθεί να μην είναι εξουσιοδοτημένη επειδή το πορτοφόλι ανήκει σε άλλον ενοικιαστή, το ποσό υπερβαίνει τις εξουσιοδοτήσεις, το αρχείο έγκρισης στοχεύει άλλον πελάτη ή το κλειδί αδυναμίας χρησιμοποιήθηκε για πρώτη φορά για διαφορετική λειτουργία.

Δοκιμαστικές περιπτώσεις:

• Η χρηματοδότηση P1 μπορεί να συμπληρώσει το W1A εντός του ορίου ποσού μετά την έγκριση.
• Η χρηματοδότηση P1 δεν μπορεί να ανανεώσει το W1B χρησιμοποιώντας μια έγκριση που δημιουργήθηκε για το W1A.
• Η χρηματοδότηση P1 δεν μπορεί να συμπληρώσει το W2A.
• Η υποστήριξη P1 δεν μπορεί να συμπληρώσει κανένα πορτοφόλι.
• Ένα διακριτικό αυτοματισμού δεν μπορεί να αλλάξει το πιστωτικό όριο εκτός εάν έχει ρητό πεδίο κίνησης χρημάτων.
• Ένα κλειδί αδυναμίας αναπαραγωγής που επαναλαμβάνεται δεν μπορεί να ανακατευθύνει μια προηγούμενη ανανέωση W1A στο W1B.

Σύσταση: χειριστείτε τα κλειδιά ανικανότητας ως εμβέλειας για συνεργάτη συν λειτουργία συν στοχευόμενο μισθωτή συν κανονικοποιημένο σώμα αιτήματος. Μια επανάληψη θα πρέπει να είναι ασφαλής, αλλά δεν θα πρέπει να γίνει κανάλι σύγκρουσης μεταξύ μισθωτών.

Αναφορές χρήσης και εξαγωγή δρομέων

Οι αναφορές χρήσης είναι εύκολο να υποπροστατεύονται επειδή είναι μόνο για ανάγνωση. Στα συστήματα μεταπωλητών, τα δεδομένα χρήσης μπορούν να αποκαλύψουν ονόματα πελατών, φόρτο εργασίας, επιλογές μοντέλων, κόστος, αναγνωριστικά τελικού χρήστη και εμπορικά περιθώρια. Cursor τα διακριτικά και τα αναγνωριστικά εξαγωγής πρέπει επίσης να δεσμεύονται από μισθωτή.

Δοκιμαστικές περιπτώσεις:

• Ο διαχειριστής του C1A μπορεί να διαβάσει τους κάδους χρήσης του C1A.
• Ο διαχειριστής C1A δεν μπορεί να διαβάσει τη χρήση του C1B αλλάζοντας το customer_id.
• Το διακριτικό ανάλυσης P1 μόνο για ανάγνωση μπορεί να εξαγάγει τη χρήση για πελάτες P1 μόνο εάν υπάρχει εύρος εξαγωγής.
• Το διακριτικό P1 δεν μπορεί να συνεχίσει την εξαγωγή χρήσης P2 με αντιγραμμένο δρομέα.
• Ένας δρομέας που δημιουργήθηκε για μια αναφορά σε επίπεδο κλειδιού δεν μπορεί να επαναχρησιμοποιηθεί για την ανάκτηση χρήσης σε επίπεδο ενοικιαστή, εκτός εάν επιτρέπεται ρητά.

Εάν η πύλη εκθέτει το AI API μέτρηση χρήσης πελατών, δοκιμάστε τόσο τις προβολές σύνοψης όσο και τις εξαγωγές με δυνατότητα λήψης. Οι διαδρομές εξαγωγής συχνά παρακάμπτουν τον ίδιο ελεγκτή ή κώδικα πολιτικής που χρησιμοποιείται από διαδραστικές σελίδες.

Δοκιμή επιπέδου ιδιότητας Authorization στο PATCH και ενημέρωση τελικών σημείων

Το επίπεδο ιδιότητας κατεστραμμένου αντικειμένου Authorization εμφανίζεται όταν επιτρέπεται σε έναν καλούντα να ενημερώσει ένα αντικείμενο, αλλά μπορεί επίσης να ορίσει πεδία που θα πρέπει να είναι εσωτερικά, προνομιακά ή να ανήκουν σε άλλη ροή εργασίας.

Για τα API συνεργατών, τα ευαίσθητα πεδία περιλαμβάνουν συχνά:

• partner_id, customer_id και πεδία γονικής ιδιοκτησίας.
• provider_project_id, provider_workspace_id και αναφορές κλειδιών ανοδικής ροής.
• pricing_catalog_version, margin_tier και παρακάμψεις έκπτωσης.
• wallet_balance, credit_limit, settlement_status και κατάσταση τιμολογίου.
• fraud_status, risk_score και σημαίες συμμόρφωσης.
• role, scopes και σημαίες παράκαμψης έγκρισης.

Χρησιμοποιήστε λίστες επιτρεπόμενων, όχι λίστες άρνησης. Για παράδειγμα, ένα τελικό σημείο ενημέρωσης προφίλ πελάτη μπορεί να επιτρέπει τα display_name, billing_email και metadata.external_reference. Θα πρέπει να απορρίψει ή να αγνοήσει τα margin_tier, credit_limit και provider_project_id, ακόμα κι αν ο καλών μπορεί να ενημερώσει το αντικείμενο πελάτη.

PATCH /partner/customers/C1A
{
  "display_name": "Acme Support Team",
  "margin_tier": "internal_zero_margin",
  "provider_project_id": "provider-project-owned-by-C1B"
}

Το αναμενόμενο αποτέλεσμα θα πρέπει να είναι ντετερμινιστικό. Προτιμήστε ένα σφάλμα επικύρωσης που προσδιορίζει τα μη επιτρεπόμενα πεδία χωρίς να αποκαλύπτει ευαίσθητες εσωτερικές τιμές. Μην αποδέχεστε σιωπηλά προνομιακά πεδία και, στη συνέχεια, αγνοήστε τα, εκτός εάν το API συμβόλαιό σας χρησιμοποιεί ήδη αυτό το μοτίβο με συνέπεια.

Κάντε τις αρνήσεις χωρίς απαρίθμηση

Οι αρνητικές δοκιμές θα πρέπει να ελέγχουν τόσο τους κωδικούς κατάστασης όσο και το σχήμα απόκρισης. Εάν ένα διακριτικό P1 ζητήσει K2A, η απάντηση δεν θα πρέπει να αποκαλύψει εάν το K2A υπάρχει σε άλλο συνεργάτη.

Ένας κοινός κανόνας είναι:

• Χρησιμοποιήστε το 401 όταν ο καλών δεν έχει πιστοποιηθεί.
• Χρησιμοποιήστε το 403 όταν ο καλών έχει πιστοποιηθεί αλλά δεν έχει πεδίο δράσης στο δικό του όριο.
• Χρησιμοποιήστε 404 ή μια γενική απάντηση που δεν βρέθηκε όταν το αντικείμενο βρίσκεται εκτός των ορίων του καλούντος και δεν πρέπει να αποκαλύπτεται η ύπαρξη.

Η ακριβής σύμβαση μπορεί να ποικίλλει, αλλά η συμπεριφορά πρέπει να είναι συνεπής. Ο φορέας άρνησης θα πρέπει να αποφεύγει μηνύματα όπως "το κλειδί ανήκει σε άλλον πελάτη" ή "το πορτοφόλι υπάρχει στον συνεργάτη P2". Αυτές οι πληροφορίες είναι χρήσιμες για τους εισβολείς και σπάνια χρήσιμες σε νόμιμους πελάτες.

Εναλλαγή: οι γενικές αρνήσεις κάνουν τον εντοπισμό σφαλμάτων πιο δύσκολο για τους συνεργάτες προγραμματιστές. Επιλύστε το πρόβλημα με αναγνωριστικά αιτημάτων, δομημένα αρχεία καταγραφής ελέγχου και εργαλεία υποστήριξης, όχι με τη διαρροή της ύπαρξης μεταξύ μισθωτών σε δημόσια API σφάλματα.

Καταγράψτε την Authorization Απόφαση, Μη ευαίσθητα ωφέλιμα φορτία

Authorization θα πρέπει επίσης να υποστηρίζουν ότι οι αρνήσεις παράγουν χρήσιμα εσωτερικά στοιχεία. Χρειάζεστε αρκετές λεπτομέρειες για να ανασυνθέσετε τι συνέβη κατά τη διάρκεια ενός περιστατικού χωρίς να αποθηκεύετε ακατέργαστα μηνύματα, μυστικά ή περιττά δεδομένα πελατών.

Τα πεδία καταγραφής πρέπει να περιλαμβάνουν:

• request_id και αναγνωριστικό συσχέτισης ίχνους.
• actor_id, τύπος ηθοποιού, αναγνωριστικό διακριτικού και πρότυπο ρόλου.
• partner_id από τον πιστοποιημένο ηθοποιό.
• Ζήτησε τον στοχευόμενο μισθωτή και επιλύθηκε τον ενοικιαστή-στόχο, όταν επιτρέπεται η επίλυση.
• Τύπος αντικειμένου και ενέργεια.
• Έκδοση πολιτικής και αποτέλεσμα απόφασης.
• Κωδικός αιτίας άρνησης, όπως missing_scope, tenant_mismatch, approval_required ή field_not_allowed.

Μην καταγράφετε πλήρη API κλειδιά, μυστικά ανάντη παρόχου, μηνύματα προτροπής, ωφέλιμα φορτία ακατέργαστης χρήσης ή πλήρες περιεχόμενο εξαγωγής. Σε περίπτωση απόρριψης αιτημάτων μεταξύ ενοικιαστών, προσέξτε ότι τα εσωτερικά αρχεία καταγραφής ελέγχονται από την πρόσβαση. η δημόσια απάντηση μπορεί να είναι γενική ενώ η ομάδα ασφαλείας έχει ακόμα αρκετά στοιχεία.

Αυτοματοποίηση της πλεξούδας σε CI και Staging

Η πλεξούδα δοκιμής θα πρέπει να εκτελείται σε τρία σημεία: δοκιμές μονάδας για συναρτήσεις πολιτικής, δοκιμές ενοποίησης για API τελικά σημεία και ανιχνευτές σταδιοποίησης σε σχέση με το αναπτυσσόμενο backend της πύλης μεταπωλητών. Κάθε επίπεδο εντοπίζει διαφορετικές αποτυχίες.

Μια πρακτική δομή CI:

authz-tests/
  fixtures/
    partners.json
    customers.json
    roles.json
    tokens.json
  matrix/
    keys.yaml
    wallets.yaml
    usage_exports.yaml
    customers.yaml
  tests/
    test_keys_authz.ts
    test_wallet_authz.ts
    test_usage_authz.ts
    test_patch_allowlists.ts

Κάθε σειρά πίνακα πρέπει να ορίζει τον παράγοντα, το αίτημα, την αναμενόμενη απόφαση και την αναμενόμενη μη απαριθμητική συμπεριφορά.

- name: p1_support_cannot_revoke_p2_key
  actor: p1_support_token
  method: POST
  path: /partner/customers/C2A/keys/K2A/revoke
  expected_status: 404
  expected_error_code: not_found
  expected_audit_reason: tenant_mismatch

Προσθέστε παραλλαγές τύπου μετάλλαξης που ανταλλάσσουν ένα αναγνωριστικό κάθε φορά: αναγνωριστικό πελάτη, αναγνωριστικό κλειδιού, αναγνωριστικό πορτοφολιού, αναγνωριστικό έγκρισης, δρομέα, κλειδί αδυναμίας και αναγνωριστικό τερματικού αγκίστρου ιστού. Αυτά τα τεστ είναι επαναλαμβανόμενα από το σχεδιασμό. Η επανάληψη είναι αποδεκτή όταν αποδεικνύει ότι κάθε αναγνωριστικό έχει ανεξάρτητα εμβέλεια.

Λειτουργική λίστα ελέγχου

Πριν αποστείλετε ένα τελικό σημείο συνεργάτη API, χρησιμοποιήστε αυτήν τη λίστα ελέγχου:

• Το τελικό σημείο έχει έναν επώνυμο κανόνα εξουσιοδότησης στη μήτρα πολιτικής.
• Κάθε αναζήτηση αντικειμένου περιλαμβάνει οριακές συνθήκες συνεργάτη και μισθωτή.
• Κάθε τελικό σημείο της λίστας φιλτράρεται κατά όριο ηθοποιού πριν από τη σελιδοποίηση.
• Κάθε δρομέας, το αναγνωριστικό εξαγωγής, το αναγνωριστικό webhook, το αναγνωριστικό έγκρισης και το κλειδί αδυναμίας έχουν εμβέλεια.
• Τα τελικά σημεία PATCH χρησιμοποιούν λίστες επιτρεπόμενων ιδιοτήτων ανά ρόλο και ενέργεια.
• Οι ενέργειες μεταφοράς χρημάτων απαιτούν ρητό πεδίο εφαρμογής και κατάσταση έγκρισης.
• Το πάγωμα έκτακτης ανάγκης διαχωρίζεται από το ξεπάγωμα και την πιστωτική αρχή.
• Οι αρνήσεις αποφεύγουν τις διαρροές ύπαρξης μεταξύ μισθωτών.
• Τα αρχεία καταγραφής ελέγχου καταγράφουν την απόφαση εξουσιοδότησης και την έκδοση πολιτικής.
• Τα ίδια αρνητικά τεστ εκτελούνται έναντι API και διαδρομών υποστήριξης πύλης.

Συμβιβασμούς για να αποφασίσετε ρητά

Τα λεπτά πεδία μειώνουν την ακτίνα έκρηξης, αλλά αυξάνουν την πολυπλοκότητα της ενσωμάτωσης συνεργάτη. Τα προεπιλεγμένα πρότυπα ρόλων βοηθούν: κάτοχος, οικονομικά, υποστήριξη, αναλυτικά στοιχεία, αυτοματοποίηση παροχής και απόκριση έκτακτης ανάγκης. Αφήστε τους προχωρημένους συνεργάτες να προσαρμόσουν από αυτά τα πρότυπα αντί να ξεκινούν από μη επεξεργασμένα πεδία.

Οι αυστηρές λίστες επιτρεπόμενων ιδιοτήτων επιβραδύνουν την κυκλοφορία λειτουργιών, επειδή κάθε νέο επεξεργάσιμο πεδίο χρειάζεται αλλαγή πολιτικής. Αυτή η τριβή είναι χρήσιμη για πεδία χρέωσης, τιμολόγησης, χαρτογράφησης παρόχου και διαχείρισης κλειδιών. Για πεδία προφίλ χαμηλού κινδύνου, η διαδικασία μπορεί να είναι πιο ελαφριά.

Οι ροές έγκρισης μειώνουν τις τυχαίες ή κακόβουλες αλλαγές πιστώσεων, αλλά προσθέτουν λανθάνοντα χρόνο στις νόμιμες λειτουργίες υποστήριξης. Διατηρήστε το πάγωμα έκτακτης ανάγκης γρήγορο, αναστρέψιμο και χωριστά. Μην αφήνετε το ίδιο διακριτικό έκτακτης ανάγκης να προσθέτει πιστώσεις, να αλλάζει περιθώρια, να εξάγει χρήση και να αποδεσμεύει λογαριασμούς.

Πρόβλεψη: οι πύλες μεταπωλητών θα συνεχίσουν να εκθέτουν περισσότερες διοικητικές ενέργειες μέσω των API συνεργατών, επειδή οι πελάτες αναμένουν παροχή αυτοεξυπηρέτησης, αναφορές και αυτοματισμό. Τα συστήματα που γερνούν καλά θα είναι αυτά με συμβόλαια εξουσιοδότησης και αρνητικά τεστ, όχι αυτά που βασίζονται μόνο στην ονομασία διαδρομής, στα κρυφά στοιχεία ελέγχου διεπαφής χρήστη ή στα αδιαφανή αναγνωριστικά.

Εκκίνητο συμπέρασμα

Δημιουργήστε τη ζώνη εξουσιοδότησης προτού ο Συνεργάτης API γίνει αρκετά μεγάλος ώστε κάθε τελικό σημείο να έχει τη δική του εξαίρεση. Ξεκινήστε με δύο συνεργάτες, δύο πελάτες κάτω από έναν συνεργάτη, έναν πελάτη κάτω από έναν άλλο συνεργάτη και ένα μικρό σύνολο κουπονιών. Στη συνέχεια, δοκιμάστε τις ενέργειες που μπορεί να σας βλάψουν περισσότερο: δημιουργία κλειδιού, ανάκληση κλειδιού, ανανεώσεις πιστώσεων, εξαγωγές χρήσης, ενημερώσεις πορτοφολιού, επαναχρησιμοποίηση έγκρισης, επανάληψη αδυναμίας και πεδία PATCH.

Η δήλωση είναι απλή: ένας καλών πρέπει να έχει το σωστό πεδίο εφαρμογής, υπό τον κατάλληλο συνεργάτη, για τον κατάλληλο μισθωτή, αντικείμενο, ιδιοκτησία, ενέργεια, ποσό και κατάσταση έγκρισης. Η εργασία υλοποίησης το κάνει αυτό αληθινό σε κάθε τελικό σημείο, συμπεριλαμβανομένων των βαρετών.

Σχετική ανάγνωση

• idempotent Partner API αυτοματισμός για παροχή κλειδιών και πιστώσεων