Securizați integrarea dvs. prin Parole sau Certificate
Puteți efectua autentificări în eGenius Platform folosind parole sau certificate SSL.
Autentificare prin parolă
Puteți să activați accesul securizat la integrările eGenius PlatformAPI și Batch prin intermediul parolelor. Parola generată de sistem este o valoare de 16 octeți, generată aleator, care este codificată ca șir de caractere hexazecimale. Deși această parolă are o lungime și o calitate suficiente pentru a rezista unui atac de tip forță brută, ar trebui securizată în același mod în care sunt securizate parolele de utilizator și alte date sensibile.
Parola dvs. este secretă și ar trebui să fie cunoscută numai de dvs. și de UniCredit Bank. Este important să păstrați confidențialitatea acestor informații pentru a vă proteja contul.
Generare parolă pentru API
Puteți genera parola API în Merchant Administration. Ca cerință preliminară, profilul dvs. de comerciant trebuie să fie activat pentru API, Batch și drepturile de „Utilizare autentificare prin parolă”.
Pentru a accesa Merchant Administration, aveți nevoie de acreditări de conectare. Acreditările de conectare ca administrator vă vor fi furnizate de către your payment service provider după ce vă înrolați cu succes pe gateway. Ca administrator, puteți crea un operator nou, cu permisiuni de generare a parolei API.
- Conectați-vă la https://egenius.unicredit.ro/ma cu acreditările de conectare ca administrator.
- Navigați la Admin > Operatori
- Creați un operator nou, completând toate câmpurile obligatorii. Atribuiți dreptul „Poate configura Setări de integrare” pentru a-i permite operatorului să genereze parola API.
- Închideți sesiunea Merchant Administration și autentificați-vă din nou în Merchant Administration ca operator nou.
- Navigați la Administrare > Setări integrare API servicii web > Editare.
- Faceți clic pe Generare nou și selectați caseta Activare acces la Integrare pe bază de parolă.
- Aceasta este parola API pe care o veți utiliza pentru a autentifica solicitările API transmise de la serverul web către gateway.
- Apăsați Trimitere.
Trebuie să aveți întotdeauna cel puțin o parolă generată și activată, dar puteți să aveți configurate până la două parole. Pentru securitate, ar trebui să modificați periodic parola. Numai o parolă trebuie utilizată pentru configurarea aplicației dvs., cea de a doua este utilizată ca rezervă pentru cazurile de tranziție între parole.
După generarea parolei, trebuie să o includeți în toate solicitările de tranzacții direcționate către eGenius Platform. Dacă solicitarea este trimisă folosind protocolul REST-JSON, solicitarea trebuie să includă userid și password în antetul de bază pentru autentificare HTTP standard. Cu NVP, pentru a utiliza API, trebuie să furnizați parametri suplimentari în solicitare, apiUsername
și apiPassword
.
Pentru autentificarea cu rolul de comerciant, numele (apiUsername
pentru NVP și userid pentru REST-JSON) și parola (apiPassword
pentru NVP și password pentru REST-JSON) trebuie să conțină 'merchant.<your gateway merchant ID>' și respectiv parola generată de sistem.
Furnizarea atât a parametrului name (nume) cât și parametrului password (parolă) sunt obligatorii de la APIv13 în continuare. Anterior v13 a fost obligatoriu să lăsați numele necompletat și să furnizați numai parola.
Referință API Parolă [REST][NVP]
Autentificare prin certificat
Autentificarea prin certificat nu este acceptată în prezent pentru API-urile
Batch sau
Reporting.
Rețineți că numele gazdei pentru autentificarea certificatului este diferit de
https://egenius.unicredit.ro/api. Vă rugăm să contactați your payment service provider pentru numele de gazdă.
În cazul autentificării prin certificat, este necesar să prezentați un certificat pentru a vă autentifica pe eGenius Platform. Certificatele sunt în mod normal emise de către una dintre multiplele organizații care operează ca Autorități de certificare (CA-uri). Acest model de autentificare este o componentă a Infrastructurii pentru chei publice (PKI), în cadrul căreia securitatea este realizată prin confidențialitate, integritate, non-repudiere și autentificare. Autoritatea de certificare (CA) asigură faptul că, cheia publică atașată unui certificat este corectă, aparține persoanei sau entității respective (adică este „autentică”) și nu a fost alterată sau modificată de o parte terță rău intenționată.
Mecanismul de autentificare pentru autentificarea prin certificat necesită ca atât clientul (serverul dvs. web) cât și serverul (eGenius Platform Serverul HTTP) să prezinte certificate pentru a realiza propria autentificare. Acest scenariu este denumit autentificare mutuală, iar procesul de autentificare este ilustrat mai jos.
Atunci când vă conectați la eGenius Platform utilizând autentificarea prin certificat, sunt realizați următorii pași:
- Clientul solicită conectarea la o resursă protejată de pe server. Acest pas are loc pentru fiecare solicitare tranzacție inițiată de către client.
- Serverul prezintă clientului propriul lanț de certificate.
- Clientul verifică certificatul serverului utilizând un depozit de încredere (trust store), care conține CA-uri rădăcină de încredere. Clientul validează calea certificatului către un certificat CA rădăcină de încredere.
- Dacă verificarea are succes, clientul trimite propriul lanț de certificate către server, lanț conținut într-un depozit de cheie.
În funcție de software-ul client al serverului web, depozitul de încredere și depozitul de cheie este adesea același.
- Serverul verifică certificatul clientului, utilizând un set complet de certificate CA rădăcină de încredere/aprobate care există încărcate pe server. Sunt realizate următoarele verificări:
- Se verifică dacă certificatul este în formatul X.509 pentru certificate.
- Se validează calea certificatului până la un certificat CA rădăcină de încredere.
- Se realizează verificarea CRL sau OCSP (Online Certificate Status Protocol) pentru a se asigura faptul că certificatul nu a fost revocat.
- Se verifică dacă certificatul nu a expirat.
După ce serverul HTTP a validat cu succes certificatul clientului, întregul lanț de certificate al clientului este transmis pentru verificare către API. Dacă nu, serverul HTTP returnează mesaje standard de eroare privind certificatul SSL.
Verificarea are loc atât la nivelul serverului HTTP cât și la nivelul API. Serverul HTTP realizează o validare completă a certificatului SSL și API realizează o autentificare la nivel de afacere a certificatului.
- API realizează următoarele verificări:
- Extrage numele comun al subiectului al certificatului clientului și confirmă că acesta corespunde numelui comun al subiectului înregistrat în baza de date pentru comerciant. Numele comun al subiectului al certificatului trebuie să conțină numele legal de companie al comerciantului.
- Verifică dacă certificatul clientului are o extensie Key-Usage, marcată ca fiind critică, care include autentificarea clientului ca una dintre utilizările permise ale certificatului.
- Realizează o validare simplă a certificatului clientului prin intermediul unui certificat CA rădăcină conținut într-un set de CA-uri permise. Aceasta înseamnă că aplicația API trebuie să stocheze certificatul CA rădăcină care a fost utilizat pentru emiterea și semnarea certificatului clientului.
Setul inițial de CA-uri permise este stabilit de către UniCredit Bank.
- Verifică dacă certificatul prezentat corespunde stării profilului comerciantului. Un profil de lucru va accepta numai certificate de lucru, în timp ce un profil de testare va accepta atât certificate de testare cât și certificate de lucru.
Dacă pașii 1-4 au succes, atunci se consideră că autentificarea comerciantului a avut succes, în caz contrar, conexiunea este respinsă prin returnarea unui mesaj de eroare corespunzător.
- Dacă toate verificările rezumate în pașii 5 și 6 au succes, serverul acceptă conexiunea și permite începerea solicitării de operațiune.
Puteți opta să prezentați certificatul dvs. client sau un certificat diferit, pentru a vă autentifica atunci când plătitorul accesează aplicația dvs. În cazul acestei interacțiuni, serverul dvs. web are rolul de server și plătitorul are rolul de client. Integrarea cu acest mecanism de autentificare poate oferi plătitorilor dvs. un plus de siguranță asupra faptului că tranzacționează cu o companie legitimă.
Obținerea Certificatului de test și de lucru de la un CA
Înainte de a începe lucrul în mediul real cu certificatul de lucru, puteți dezvolta și testa autentificarea PKI cu un certificat de test. Aceasta ar putea fi utilă, de exemplu, dacă nu doriți să partajați certificatul de lucru și cheia privată cu un integrator web terț.
Este important ca certificatul pe care îl obțineți de la CA-ul ales să respecte cerințele UniCredit Bank referitoare la implementarea certificatelor. În continuare sunt prezentate câteva puncte cheie pe care să le luați în calcul la obținerea certificatului dvs. SSL.
- Certificatul trebuie să fie în formatul X.509 pentru certificate.
- Certificatul trebuie să aibă o extensie Key-Usage marcată ca fiind critică și să includă autentificarea clientului ca una dintre utilizările permise ale certificatului.
- Certificatul trebuie să fie emis de un CA aprobat de către UniCredit Bank. Contactați UniCredit Bank pentru a obține o listă a CA-urilor aprobate.
- Numele comun al subiectului (CN) certificatului trebuie să conțină numele de domeniu complet calificat (cu sau fără wildcard) al site-ului web pentru care este achiziționat certificatul.
- Câmpul organizație subiect (O) trebuie să conțină organizația comerciantului.
Configurarea Certificatelor comerciant în Administrator comercianți
După obținerea certificatului de la un CA cunoscut, your payment service provider trebuie să vă configureze certificatul de test și/sau de lucru în Administrator comercianți atunci când configurează setările API pentru profilul dvs. de comerciant de pe gateway. Dacă este necesar, un certificat comerciant poate fi legat la mai multe profiluri comerciant din cadrul aceleiași companii sau din companii diferite. Pentru mai multe informații despre modul de configurare a certificatelor de comerciant în Administrator comercianți, consultați secțiunea Configurarea API din Ghidul de utilizare pentru Administrator comercianți.
Site-ul controlează lista certificatelor CA rădăcină acceptate care sunt utilizate pentru verificarea certificatelor comerciant. Pentru a activa verificarea certificatelor, sistemul colectează versiunea codificată PEM a certificatului de lucru prin Administrator comercianți. Numele comun al subiectului este extras din acest certificat și este verificat pe baza Numelui comun al subiectului din certificatul prezentat în decursul dialogului de confirmare SSL.
Atâta vreme cât reînnoiți certificatul dvs. cu un nume de subiect identic cu cel din certificatul expirat, nu este necesară actualizarea configurației în Administrator comercianți. Această caracteristică se datorează faptului că sistemul salvează doar Numele Comun al Subiectului din cadrul certificatului, ca metodă de validare a certificatului.
Integrarea Certificatului SSL cu aplicația dvs.
După configurarea certificatului pentru profilul dvs. de comerciant, trebuie să efectuați următorii pași pentru a instala certificatul în mediul dvs.
- Marcați cheia privată și certificatul ca disponibile pentru software-ul client SSL care realizează conexiunea SSL la eGenius Platform. În funcție de software, este posibil să fie necesară conversia la un format acceptat a cheii private, certificatului și lanțului de certificate asociat. De exemplu, cheile private și certificatele sunt obținute adesea în fișiere text, în format PEM, cu cheia privată protejată cu ajutorul unei parole. În Java, aceste fișiere sunt în mod normal încărcate într-un depozit de cheie Java. Vă rugăm să consultați documentația software-ului dvs. pentru informații despre formatele acceptate.
Pentru mediile Java și .NET vă recomandăm să realizați conversia fișierelor PEM în format PKCS12.
- În aproape toate cazurile, CA-ul emitent al certificatului dvs. furnizează certificate suplimentare, denumite lanț de certificate. Acestea trebuie furnizate către eGenius Platform în momentul dialogului de confirmare SSL, pentru a permite gateway-ului să valideze certificatul. Software-ul dvs. client SSL va oferi instrucțiuni referitoare la cum și unde trebuiesc salvate aceste certificate.
- Un test simplu pentru a verifica dacă aveți toate certificatele necesare se realizează prin încărcarea acestora într-un browser web, ca de exemplu Internet Explorer, Firefox sau Safari și accesarea adresei URL API Check Gateway de pe gateway pentru apelarea stării gateway-ului. Dacă certificatele sunt încărcate corect, accesarea Adresă URL pentru Check Gateway va face ca browserul să vă solicite selectarea/acceptarea certificatului ce va fi utilizat pentru conectarea la gateway. Dacă browserul vă solicită selectarea certificatului și se realizează cu succes o conexiune, veți primi următorul răspuns: {status: "OPERATING"}.
Majoritatea browserelor vor necesita, de asemenea, conversia certificatelor formatate PEM. Astfel, utilizarea browserului pentru a testa corectitudinea certificatelor va confirma, de asemenea, faptul că puteți realiza cu succes conversia certificatelor în formatul corespunzător. Internet Explorer acceptă următoarele formate: PKCS#12, PKCS#7 și Microsoft Serialized Certificate Store. Utilitarul OpenSSL este un instrument excelent pentru conversia între formatele pe baza standardelor PEM și PKCS.
Referință API URL Check Gateway [REST][NVP]
Tranziționarea certificatelor
Este posibil să doriți să tranziționați de la certificatul existent la un nou certificat, din diverse motive. De exemplu, pentru a face upgrade certificatului pentru modificarea numelui companiei sau pentru tranziția de la un certificat de testare la un certificat de lucru.
Pentru a trece la un certificat nou, your payment service provider trebuie să adauge noul certificat ca certificat principal, în timp ce certificatul vechi devine un certificat suplimentar. Puteți avea unul sau mai multe certificate suplimentare. Comercianții configurați pentru utilizarea noului certificat se pot autentifica la API utilizând fie certificatul vechi, fie certificatul nou. Aceasta are rolul unei configurații de tranziție, până în momentul în care pentru toate integrările a fost realizat upgrade pentru utilizarea noului certificat. Pentru mai multe informații despre adăugarea de certificate suplimentare, consultați secțiunea Configurarea API din Ghidul de utilizare pentru Administrator comercianți.
Autentificarea sesiunii
Autentificarea sesiunii utilizează sesiunea de plată de pe gateway, un container temporar pentru câmpuri de solicitare, pentru autentificarea unui comerciant. Deoarece sesiunea de plată este creată de un comerciant autentificat (folosind autentificarea prin parolă/certificat), plătitorul o poate utiliza pentru interacțiunile cu gateway-ul, cum ar fi efectuarea de operațiuni de autentificare.
Acest mecanism de autentificare permite plătitorilor să își introducă detaliile de plată direct pe gateway. Datele plătitorilor sunt obținute printr-o interacțiune a clientului cu gateway-ul, fie prin browserul plătitorului, fie printr-o aplicație de pe dispozitivul mobil al plătitorului. Acest lucru oferă un model simplu de integrare pentru obținerea securizată a datelor necesare ale plătitorului, deoarece solicitările API-ului către gateway sunt efectuate direct de pe client, nu pe server.
Acest proces utilizează un mecanism de autentificare HTTP (similar cu autentificarea prin parolă) în care trebuie să furnizați valoarea „merchant.<your gateway merchant ID>>” în secțiunea userid și ID-ul sesiunii în secțiunea password.
Autentificarea sesiunii este disponibilă în API începând cu v55.
Pentru a utiliza acest tip de autentificare:
- Creați o sesiune trimițând o solicitare Create Session în API de pe serverul dvs. către serverul gateway-ului. Această operațiune va returna un ID de sesiune.
- Trimiteți solicitarea Update Session utilizând autentificarea sesiunii pentru a adăuga orice date relevante la sesiunea creată la pasul 1.
- Furnizați sesiunea plătitorului.
Tranzacțiile acceptate
Următoarele operațiuni permit autentificarea cu ajutorul unui ID de sesiune.
- Update Session
- Initiate Authentication
- Authenticate Payer
Câmpurile completate de plătitor și cele returnate către plătitor
În interacțiunile cu gateway-ului bazate pe autentificarea sesiunii, plătitorul este limitat la un subset de câmpuri din cadrul operațiunii API. Acestea poartă numele de câmpuri completate de plătitor. Dacă solicitare efectuată pe baza autentificării sesiunii conține și alte câmpuri decât cele completate de plătitor, solicitarea va fi respinsă. De exemplu, plătitorul nu poate trimite date precum valoarea comenzii.
În mod similar câmpurilor completate de plătitor, gateway-ul permite doar returnarea anumitor câmpuri ca răspuns la interacțiunile cu gateway-ul efectuate în urma autentificării sesiunii. Acestea poartă numele de câmpuri returnate către plătitor —. Sunt returnate numai câmpurile care trebuie afișate pentru plătitor în browser sau aplicație, în vederea efectuării tranzacției. De exemplu, datele sensibile de securitate, precum ID-ul sesiunii, nu sunt returnate.
Update Session
Câmpuri completate de plătitor
- billing.address.city
- billing.address.company
- billing.address.country
- billing.address.postcodeZip
- billing.address.stateProvince
- billing.address.stateProvinceCode
- billing.address.street
- billing.address.street2
- browserPayment.preferredLanguage
- correlationId
- customer.dateOfBirth
- customer.email
- customer.firstName
- customer.lastName
- customer.mobilePhone
- customer.nationalId
- customer.phone
- customer.taxRegistrationId
- device.browser
- device.browserDetails.3DSecureChallengeWindowSize
- device.browserDetails.acceptHeaders
- device.browserDetails.colorDepth
- device.browserDetails.javaEnabled
- device.browserDetails.language
- device.browserDetails.screenHeight
- device.browserDetails.screenWidth
- device.browserDetails.timeZone
- device.fingerprint
- device.hostname
- device.ipAddress
- device.mobilePhoneModel
- gatewayEntryPoint
- locale
- merchant
- order.id
- order.walletProvider
- session.version
- shipping.contact.email
- shipping.contact.firstName
- shipping.contact.lastName
- shipping.contact.mobilePhone
- shipping.contact.phone
- sourceOfFunds.provided.card.devicePayment.3DSecure.eciIndicator
- sourceOfFunds.provided.card.devicePayment.3DSecure.onlinePaymentCryptogram
- sourceOfFunds.provided.card.devicePayment.cryptogramFormat
- sourceOfFunds.provided.card.devicePayment.emv.emvData
- sourceOfFunds.provided.card.devicePayment.paymentToken
- sourceOfFunds.provided.card.expiry.month
- sourceOfFunds.provided.card.expiry.year
- sourceOfFunds.provided.card.mobileWallet.emv.emvData
- sourceOfFunds.provided.card.nameOnCard
- sourceOfFunds.provided.card.number
- sourceOfFunds.provided.card.provided.card.prefix
- sourceOfFunds.provided.card.securityCode
- sourceOfFunds.token
- sourceOfFunds.type
- transaction.acquirer.customData
- transaction.acquirer.traceId
- transaction.id
Câmpuri returnate către plătitor
- correlationId
- error.cause
- error.field
- error.supportCode
- error.validationType
- order.amount
- order.currency
- order.customerNote
- order.customerReference
- order.invoiceNumber
- result
- session.updateStatus
- session.version
Initiate Authentication
Câmpuri completate de plătitor
- apiOperation
- correlationId
- order.walletProvider
- session.id
- session.version
- sourceOfFunds.provided.card.devicePayment.3DSecure.eciIndicator
- sourceOfFunds.provided.card.devicePayment.3DSecure.onlinePaymentCryptogram
- sourceOfFunds.provided.card.devicePayment.cryptogramFormat
- sourceOfFunds.provided.card.devicePayment.emv.emvData
- sourceOfFunds.provided.card.devicePayment.paymentToken
- sourceOfFunds.provided.card.number
- sourceOfFunds.token
- sourceOfFunds.type
Câmpuri returnate către plătitor
- authentication.3ds2.methodCompleted
- authentication.3ds2.methodSupported
- authentication.redirect.customized.3DS.methodPostData
- authentication.redirect.customized.3DS.methodUrl
- authentication.redirectHtml
- authentication.version
- correlationId
- error.cause
- error.field
- error.supportCode
- error.validationType
- order.authenticationStatus
- order.currency
- order.status
- response.gatewayCode
- response.gatewayRecommendation
- result
- sourceOfFunds.provided.card.number
- sourceOfFunds.type
- transaction.authenticationStatus
- version
Authenticate Payer
Câmpuri completate de plătitor
- apiOperation
- billing.address.city
- billing.address.company
- billing.address.country
- billing.address.postcodeZip
- billing.address.stateProvince
- billing.address.stateProvinceCode
- billing.address.street
- billing.address.street2
- correlationId
- device.browser
- device.browserDetails.3DSecureChallengeWindowSize
- device.browserDetails.acceptHeaders
- device.browserDetails.colorDepth
- device.browserDetails.javaEnabled
- device.browserDetails.language
- device.browserDetails.screenHeight
- device.browserDetails.screenWidth
- device.browserDetails.timeZone
- device.ipAddress
- order.walletProvider
- session.id
- session.version
- sourceOfFunds.provided.card.devicePayment.3DSecure.eciIndicator
- sourceOfFunds.provided.card.devicePayment.3DSecure.onlinePaymentCryptogram
- sourceOfFunds.provided.card.devicePayment.cryptogramFormat
- sourceOfFunds.provided.card.devicePayment.emv.emvData
- sourceOfFunds.provided.card.devicePayment.paymentToken
- sourceOfFunds.provided.card.expiry.month
- sourceOfFunds.provided.card.expiry.year
- sourceOfFunds.provided.card.number
- sourceOfFunds.provided.card.securityCode
Câmpuri returnate către plătitor
- authentication.3ds2.acsReference
- authentication.3ds2.challenge.signedContent
- authentication.3ds2.methodCompleted
- authentication.3ds2.methodSupported
- authentication.3ds2.sdk.interface
- authentication.3ds2.sdk.timeout
- authentication.3ds2.sdk.uiType
- authentication.payerInteraction
- authentication.redirect.customized.3DS.acsUrl
- authentication.redirect.customized.3DS.cReq
- authentication.redirect.domainName
- authentication.redirectHtml
- authentication.version
- correlationId
- encryptedData.ciphertext
- encryptedData.nonce
- encryptedData.tag
- error.cause
- error.field
- error.supportCode
- error.validationType
- order.authenticationStatus
- order.currency
- order.status
- response.gatewayCode
- response.gatewayRecommendation
- result
- sourceOfFunds.provided.card.number
- sourceOfFunds.type
- transaction.authenticationStatus
- version
Protejarea informațiilor plătitorului prin SSL
Toate site-urile web care colectează informații sensibile sau confidențiale trebuie să protejeze datele comunicate între browserul Internet al plătitorului, aplicație și eGenius Platform.
SSL este o tehnologie de securitate care este utilizată pentru a securiza tranzacțiile între serverul web și browserul Internet. Acestea includ securizarea oricăror informații (ca de exemplu numărul de card de credit al plătitorului) transmise de către un browser Internet către un server web (ca de exemplu aplicația dvs. web „Caută & Cumpără”). SSL protejează datele trimise pe Internet împotriva interceptării și vizualizării de către destinatari neintenționați.
Când implementați Direct Payment, trebuie să vă asigurați că aplicația dvs. prezintă un formular securizat care utilizează SSL. De asemenea, ar trebui să luați în calcul utilizarea unui formular securizat în cadrul aplicației dvs. pentru colectarea informațiilor confidențiale, ca de exemplu, adresa plătitorului.
Cum văd plătitorii mei dacă site-ul meu utilizează SSL?
Când un plătitor se conectează la aplicația dvs. utilizând SSL, acesta va vedea că http:// se transformă în https:// și, de asemenea, în browserul Internet apare imaginea unui mic lacăt auriu, de exemplu:
De fiecare dată când un browser web se conectează la un server web (site web) prin https://, acest lucru înseamnă că sesiunea de comunicație cu eGenius Platform va fi criptată și securizată. Puteți să le atrageți atenția plătitorilor dvs. asupra acestui fapt, astfel încât să știe ce semnale să urmărească atunci când tranzacționează pe site-ul dvs. web.
Tabel de referință pentru principalele diferențe dintre modelele de securitate
Următorul tabel schițează unele diferențe principale dintre modelele de autentificare prin parolă și prin certificat, cu intenția de a vă ajuta să selectați soluția de autentificare care întrunește cel mai bine necesitățile de autentificare ale companiei dvs.
|
Autentificare prin parolă |
Autentificare prin certificat |
Când să utilizați soluția
|
În cazul companiilor mici, unde autentificarea simplă întrunește necesitățile. |
În cazul companiilor mari, unde costul de infrastructură pentru implementarea PKI este minim, comparativ cu securitatea obținută cu ajutorul unui nivel sporit de securitate a autentificării. |
Aptitudini tehnice necesare
|
Este necesară cunoașterea autentificării HTTP de bază |
Este necesară cunoașterea autentificării mutuale și PKI utilizând Autorități de certificare (CA) |
Ușurința integrării
|
Ușor de integrat |
Configurarea fișierului depozit de cheie și a altor părți ale infrastructurii poate mări complexitatea integrării. |
Nivel de autentificare |
Moderat |
Înalt |
Cost |
Cea mai ieftină metodă de autentificare care poate fi utilizată. |
Implică costuri suplimentare, ca de exemplu costul de abonare la autoritatea de certificare pentru emiterea certificatelor SSL. |
Avantaje |
Ideal pentru comercianții mai mici, în cazul cărora costul integrării este un factor important și modelele de afacere nu necesită niveluri sporite de securitate. |
Autentificarea SSL reciprocă oferă un înalt nivel de securitate și este considerată una dintre cele mai bune practici în domeniu. Aceasta optimizează performanțele autentificării prin utilizarea conexiunii SSL existente, conexiune care în mod normal este oricum creată. Consumul suplimentar de date datorat trimiterii certificatului clientului este minim. |
Dezavantaje |
Parola este încorporată în format cleartext în antetul de autentificare HTTP și trebuie trimisă numai prin SSL. eGenius Platform acceptă doar conexiuni protejate SSL, astfel protejând parola de o eventuală dezvăluire; totuși, este foarte important pentru securitatea conexiunii să se realizeze o autentificare corespunzătoare a serverului pentru a preveni dezvăluirea accidentală către servere rău intenționate. |
Fără |
Asistență pentru partajarea acreditărilor pentru mai multe profiluri comerciant |
Parolele nu pot fi partajate între mai multe profiluri de comerciant |
Permite partajarea unui ID set de certificate între mai multe profiluri comerciant din cadrul aceluiași MSO și MSO-uri diferite (pe baza de drepturi). |