Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Alle brukere som skal ha smartkort med kvalifiserte sertifikater (QC) og/eller ID@Work må være forhåndsregistrert hos Buypass før sertifikat kan utstedes.

Forhåndsregistrering er en verifikasjon av personlig informasjon om brukeren. Kombinasjon fullt navn og fødselsnummer (FNR/DNR) sjekkes mot Folkeregister (FREG). Brukeren må være registrert i FREG og kombinasjonen navn / fødselsnummer må finnes og stemme, ellers vil det bli gitt en feilmelding i BAM-klienten.

Hvis konfigurasjonen av BAM-klienten er satt opp med Mixed Mode må Bruker være registrert i lokal AD før forhåndsregistrering er mulig.

Hvis konfigurasjonen av BAM-klienten er satt opp med Buypass Mode brukes ikke lokal AD, men brukeren vil bli sjekket og preregistrert direkte hos Buypass.


Det er flere måter å forhåndsregistrere:

  1. BAM-klient: Èn og èn – kun en bruker av gangen

  2. BAM-klient: Batch- eller masseregistrering - en eller flere brukere samtidig ved bruk av filinput (forskjellig metode i BAM v3.7.6 og BAM v3.8.1)

  3. Scim-api: Se beskrivelse på egen side - BAS SCIM API documentation

EN bruker

RA-ADMIN må logge på BAM klient og starte funksjonen "Preregistrer bruker hos Buypass" fra administrasjonsmenyen.

Operatøren søker etter riktig bruker ved å legge inn et eller flere kriterier i søkefeltene – Operatør må velge kun én bruker fra resultatlisten.

BAM-klientens Mode vil avgjøre hvordan søk gjennomføres og hvor data hentes fra / sjekkes mot:

  1. Mixed Mode (utstedelse av både LC og QC): Det søkes mot lokal AD og Buypass i parallell basert på hva som er definert som Brukernavn/IssuerKey *. Person må finnes i AD for å bli preregistrert. Dersom person allerede finnes hos Buypass med denne eller annen IssuerKey eller IssuerKey er knyttet til annen person gis det meldinger om dette.

  2. Buypass Mode (utstedelse av kun QC): Det søkes kun mot Buypass basert på hva som er definert som Brukernavn/IssuerKey *. Dersom person allrede finnes hos Buypass med denne eller annen IssuerKey eller IssuerKey er knyttet til annen person gis det meldinger om dette.

*) Se Master_AD_Mapping Employee i Configuration Application Tool.


Informasjon som skal registreres:

  1. Brukernavn/IssuersKey (obligatorisk)

  2. FNR/DNRfornavnetternavn (obligatorisk)

  3. Epost (valgfritt)

  4. UPN - User Principle Name (valgfritt) - nytt fra 3.8.0

  5. Sertifikattype (obligatorisk) - nytt fra 3.8.0 - feltet vil være utfylt med standard verdier for Organisasjonen, så om Bruker skal ha andre kombinasjoner må det endres av Operatør.

    1. ID@Work - Buypass ID i mobil for brukere tilknyttet organisasjoner med sentrallagrede QC som aksesseres fra brukers Buypass mobilAPP

    2. QC på smartkort - Buypass ID med QC på brukeres ansattkort  

 

Lovlige verdier i navn er: a-zàáâãäåæèéêëìíîïñòóôõöøùúûüýÿA-ZÀÁÂÃÄÅÆÈÉÊËÌÍÎÏÑÒÓÔÕÖØÙÚÛÜÝ i tillegg til blank (space), bindestrek (-) og apostrof (') - ikke tall.

Fødselsnummer (FNR/DNR) må være på formatet:

  • Fødselsdato - 6 siffer på formatet ddmmåå

  • Personnummer - 5 siffer på formatet nnnnn

Etter registrering vil Operatør få enten OK / IKKE OK i retur. Hvis IKKE OK må navn og fødselsnummer sjekkes. Om det er registrert i AD må det kontrolleres før nytt forsøk (Mixed Mode).  Kombinasjonen skal være korrekte og matche det som er registrert i FREG.


NB! Dersom epost oppgis blir det lagt inn i Subject Alternative (SAN) - feltet i sertifikatet (default) 
NB! Dersom UPN oppgis må Organisasjonen selv be om at Buypass setter opp sertifikatprofilen slik at også dette legges inn i Subject Alternative (SAN) - feltet i sertifikatet 

(lightbulb)  Gjør oppmerksom på at eksempelet om viser SAN-feltet for et sertifikat kun viser hvordan dette vil se ut når både epost og UPN legges i sertifikatet - innholdet er fra et testmiljø og som dere ser er ikke feltene samstemt.

FLERE brukere

- batch

RA-ADMIN må logge på BAM klient og starte funksjonen "Batch Preregistrering" fra administrasjonsmenyen.

BAM-klientens Mode vil avgjøre hvordan søk gjennomføres og hvor data hentes fra / sjekkes mot:

  1. Mixed Mode (utstedelse av både LC og QC): Det søkes mot lokal AD og Buypass i parallell basert på hva som er definert som Brukernavn/IssuerKey *. Person må finnes i AD for å bli preregistrert. Dersom person allerede finnes hos Buypass med denne eller annen IssuerKey eller IssuerKey er knyttet til annen person gis det meldinger om dette.

  2. Buypass Mode (utstedelse av kun QC): Det søkes kun mot Buypass basert på hva som er definert som Brukernavn/IssuerKey *. Dersom person allrede finnes hos Buypass med denne eller annen IssuerKey eller IssuerKey er knyttet til annen person gis det meldinger om dette.

*) Se Master_AD_Mapping Employee i Configuration Application Tool.

I batch preregistrering vil det bli benyttet to typer filer: a) inputfil som brukes som kilde for informasjon om hver bruker, og b) resultatfil som gir tilbakemelding fra preregistreringen.Filformatene og verdier som kan registreres er forskjellig avhengig av BAM-versjon. Se nedenfor for BAM v3.7.6 og BAM v3.8.1.


Innhold denne siden:

Table of Contents

Page Tree
expandCollapseAlltrue
startDepth1
searchBoxtrue

konfigurert til å tilordne e-post til et bestemt AD-felt for e-post.

b) Resultatfil

En resultatfil vil bli generert når inputdataene er validert OK og en eller flere av brukerne er preregistrert. Filen inneholder oversikt over både OK-transaksjoner, men også transaksjoner med feil hvis det er noen. Formatet til resultatfilen er lik inputfilen, men vil ha to ekstra kolonner for resultatmeldinger.

Resultatfilen lagres automatisk i samme katalogen som inputfilen med samme filnavn utvidet med _LtsResult (<ImportedFileName>_LtsResult.csv). Dette er også en kommaseparert "csv" fil.

Feil kan rettes og lagres i en ny inputfil eller tilbake i opprinnelig fil. Hvis en inputfil er korrigert og kjøres på nytt og en bruker allerede er preregistrert OK i første kjøring vil denne brukeren bli ignorert når filen kjøres annen eller tredje gang.

Image RemovedImage Removed

Hvis forhåndsregistrering var OK vil resultatet være TRUE i kolonnen IsPreRegisterOk.
Hvis forhåndsregistrering var IKKE OK vil resultatet være FALSE i kolonnen IsPreRegisterOk, og en forklaring vil bli gitt i kolonnen ResultMessage.

Steg for steg guide for batch preregistrering v3.7.6

På det første trinnet importeres en forhåndsdefinert inputfil som inneholder brukere med tilknyttet registreringsinformasjon.

Trykk HENT FIL og velg fil som skal importers.

  • På neste trinn valideres inputfilen ved at det kjøres en analyse av dataene i filen.

    Hvis alt er OK og dataene ikke har valideringsfeil vil det kun bli gitt beskjed om hvor mange brukere som vil bli preregistrert når du som Operatør taster PIN og går videre i prosessen.

    Hvis alt ikke er OK og dataene har valideringsfeil vil det bli gitt beskjed om hvor mange brukere som er importert, hvor mange som har valideringsfeil og hvor mange som vil bli preregistrert når du som Operatør taster PIN og går videre i prosessen.

    Du vil få en oversikt over de brukerne som har en valideringsfeil, slik at du har mulighet til å rette disse før du går videre og preregistrerer. Du kan velge å preregistrere de som er OK først før du retter de som er feil – da taster du PIN og går til neste punkt.

    Du kan trykke på "Åpne" for å se innholdet i inputfilen din "-filen, og eventuelt endre/rette de valideringsfeil som er angitt i listen. Du kan bruke vanlige navigeringsknappene til å navigere gjennom alle valideringsfeilene. Informasjon om feil blir gitt i kolonnen "Feilbeskrivelse".

    I eksempelet i skjermbildet mangler fornavn på den første personen og FNR har ikke innledende null (080761…) i fødselsdato på den andre personen.

    LAST IGJEN-knappen kan brukes til å velge samme eller en annen inputfil. Det er jo greit dersom du har ÅPNET inputfilen, rettet feil, lagret denne og nå kan lese den inn igjen på nytt for å gå videre for å preregistrere alle.

  • Siste steg er selve preregistreringen.

    Etter at du har tastet din Operatør-PIN og trykket på IDENTIFISER vil selve preregistreringsprosessen starte for de antall brukere som ble angitt. Det vil ta cirka to sekunder å preregistrere hver bruker.

    Samlet resultatinformasjon vil bli gitt etter at alle er preregistrert. Antall brukere som er registrert vil bli vist. Fil med resultater vil bli opprettet i samme katalog som den opprinnelige inputfilen med navnet <ImportedFileName> _LtsResult.csv.

    Dersom noen ikke preregistreres vil det bli gitt en beskrivelse av feilsituasjonen i kolonnen Feilbeskrivelse. Du kan ÅPNE resultatfilen og se på hvilke som har gått bra og hvilke som ikke har gått bra. Du kan rette eventuelle feil i ny fil og preregistrere på nytt, eller du kan rette feil i den originale inputfilen og preregistrere på nytt. Om en allerede er preregistrert OK får du bare meldingen at bruker er preregistrert allerede.

  • Anchorbatchv3.8.1batchv3.8.1BAMv3.8.1

    Anchor
    batchv3.78.6batchv3.7.6

    BAM v3.7.6

    a) Inputfil

    Operatøren må ha en ". csv" fil tilgjengelig med all nødvendig informasjon om brukerne som skal forhåndsregistreres. Filen kan redigeres i en hvilken som helst editor - i de gitte eksemplene bruker vi Excel som editor og .csv som filtype.

    Filen for import må inneholde en header - det kan være hva som helst, men det må ikke være tom. MERK: Endring av kolonneposisjoner er ikke mulig.

    Filen kan lagres hvor som helst - enten på BAM-PC eller på et fileshare, men BAM-klienten må ha tilgang gjennom browsing. Når du lagrer filen husk:

    • Filtype: CSV (kommaseparert) 

    • Format: UTF-8

    Feilene kan rettes og lagres i en ny inputfil eller i den opprinnelige filen. Hvis en inputfil kjøres på nytt og en bruker allerede er preregistered OK vil brukeren bli ignorert når filen kjøres annen gang.

    Image Removed

    I Notepad ser filen slik ut:

    Image Removed

    EmployeeID er BrukerID eller brukernavn og unike IssuerKey (oppslagsindeks) for brukeren i kommunikasjon med Buypass.

    FNR/DNR og må være 11 siffer. Fødselsdag med første til og med niende må ha ledende nuller som 01 ... 09 i FNR-feltet. 
    (warning) Dersom IssuerKey er FNR/DNR skal FNR/DNR legges inn i både 1 og 2 kolonne.

    Lovlige verdier i navn er: a-zàáâãäåæèéêëìíîïñòóôõöøùúûüýÿA-ZÀÁÂÃÄÅÆÈÉÊËÌÍÎÏÑÒÓÔÕÖØÙÚÛÜÝ i tillegg til blank (space), bindestrek (-) og apostrof (') - ikke tallE-post er valgfritt, og kan utelates. De fleste bedrifter bruker UPN og registrerer ikke "offisielle" e-post i AD. BAM-klienten er derfor ikke

    1
    batchv3.8.1

    Batch preregistrering i BAM v 3.8.1 og senere versjoner

    Antall attributter eller informasjon som skal preregistreres om en Bruker er utvidet , og for å få til de samme utvidelsene i batch preregistrering er filformatet endreti forhold til tidligere versjoner. Vi støtter ikke lenger .CSV-format, men har innført støtte for .JSON og .XML format.

    1. Brukernavn/IssuersKey (obligatorisk)

    2. FNR/DNRfornavnetternavn (obligatorisk)

    3. Epost (valgfritt)

    4. UPN - User Principle Name (valgfritt) - nytt fra 3.8

    5. Sertifikattype (obligatorisk) - nytt fra 3.8 - feltet vil være utfylt med standard verdier for Organisasjonen, så om bruker skal ha andre kombinasjoner må det endres av Operatør.

      1. ID@Work - Buypass ID i mobil for brukere tilknyttet organisasjoner med sentrallagrede QC som aksesseres fra brukers Buypass mobilAPP

      2. QC på smartkort - Buypass ID med QC på brukeres ansattkort  


    Strukturen på resultatfilen er den samme som inputfilen med et tillegg på 2 felt:

    • IsProcessedSuccessfully - inneholder TRUE hvis preregistrering eller oppdater registrering (se Oppdater Brukerinformasjon) er OK, ellers settes den til FALSE

    • ResultMessage - inneholder OK hvis preregistrering eller oppdater registrering er OK, ellers fås en feilmelding

    Resultatfilen kan brukes som ny inputfil uten å fjerne disse feltene. Alle record-linjene med feltet IsProcessedSuccessfully = TRUE vil bli ignorert ved innlesning.

    I MixedMode må brukerne være registrert i AD. 


    Email og UPN

    • Dersom feltene EMAIL og UPN ikke er spesifisert i inputfilen blir feltene i Buypass database heller ikke fylt ut 

    • NB! Det betyr at EMAIL og UPN ikke legges ut som attributter i SAN-feltet i sertifikatene, dersom det er spesifisert i sertifikatprofilen for Organisasjonen 


    Sertifikattyper

    • Dersom feltene Feltene IsIdAtWorkIssueAllowed eller IsSmartCardIssueAllowed ikke er spesifisert i inputfilen vil default verdier for Brukerstedet (Issuer) brukes. 

    • Default verdier for sertifikattype er at smartkort skal utstedes og ID@Work ikke skal utstedes

    Feltene IsProcessedSuccessfully og ResultMessage er ikke nødvendig å ta med i inputfilen, men dersom resultatfilen blir brukt som inputfil etter korrigeringer vil du se feltene som i kodeeksemplene nedenfor. 
    Som nevnt ovenfor - Resultatfilen kan brukes som ny inputfil uten å fjerne disse feltene. Alle record-linjene med feltet IsProcessedSuccessfully = TRUE vil bli ignorert ved innlesning.

    • og IsSmartCardIssueAllowed spesifiseres i inputfilen


    Preregistration filstruktur med XML / JSON

    XML

    Code Block
    languagexml
    <Employees>
      <Employee>
        <EmployeeId>pehj</EmployeeId>
        <FirstName>PETRA PSA</FirstName>
        <LastName>HJORT</LastName>
        <SSN>08074900276</SSN>
        <Email>petra.hjort@buypass.no</Email>
        <UPN>pehj@buypass.no</UPN>
        <IsIdAtWorkIssueAllowed>false</IsIdAtWorkIssueAllowed>
        <IsSmartCardIssueAllowed>true</IsSmartCardIssueAllowed>
        <IsProcessedSuccessfully>false</IsProcessedSuccessfully>
        <ResultMessage></ResultMessage>
      </Employee>
    </Employees>

    JSON

    Code Block
    languagexml
    [
     {
       "EmployeeId": "pehj",
       "FirstName": "PETRA PSA",
       "LastName": "HJORT",
       "SSN": "08074900276",
       "Email": "petra.hjort@buypass.no",
       "UPN": "pehj@buypass.no",
       "IsIdAtWorkIssueAllowed": false,
       "IsSmartCardIssueAllowed": true,
       "IsProcessedSuccessfully": false,
       "ResultMessage": ""
     },
     {
       "EmployeeId": "056bbk",
       "FirstName": "Lilian",
        ...... and so on...
     }
    ]
    Anchorscimscim

    Scim-api

    Base URLs

    Environment

    URL

    production

    https://api.buypass.no/access-scim-api

    • Client ID: Oppgis ved forespørsel

    • Client Secret: Oppgis ved forespørsel

    • Response Type: token

    test4

    https://api.test4.buypass.no/access-scim-api 

    • Client ID: Oppgis ved forespørsel

    • Client Secret: Oppgis ved forespørsel

    • Response Type: token

    Scim-api Docs - test4

    https://api.test4.buypass.no/access-scim-api  gir redirect til swagger, eller
    https://api.test4.buypass.no/access-scim-api/swagger

    • Brukernavn: Oppgis ved forespørsel

    • Passord: Oppgis ved forespørsel

    API Endpoints

    Endpoint

    Description

    /Tenants/{tenant_id}/Users

    Retrieve, add and modify users.

    /Schemas

    Retrieve one or more supported schemas.

    /ResourceTypes

    Retrieve supported resource types.

    /ServiceProviderConfig

    An HTTP GET to this endpoint will return a JSON structure that describes the SCIM specification features available on a service provider.

    API Schemas

    • urn:ietf:params:scim:schemas:core:2.0:User

    • urn:ietf:params:scim:schemas:extension:buypass:2.0:upn:User 

    Core

    Field

    Description

    Example

    Required

    Mutablitity

    userName

    Unique identifier for the user, used by the user to directly authenticate with the service provider. Must be the Norwegian National Person Identifier.

    Code Block
    "userName" : "01026201590"

    Required

    Immutable

    externalId

    An identifier for the User as defined by the customer

    Code Block
    "externalId": "701984"

    Required

    ReadWrite

    name

    The user's real name

    Code Block
    "name": {
       "familyName": "Jensen",
       "givenName": "Barbara",
       "middleName": "Jane"
     }
    

    Required

    ReadOnly

    phoneNumbers

    The user's phone number in E.164 format. Only one phone number is supported

    Code Block
    "phoneNumbers":[
       {
          "value":"+4755555555"
       }
    ]
    

    Optional

    ReadWrite

    emails

    The user's email address. Only one email address is supported.

    Code Block
    "emails":[
       {
          "value":"bjensen@example.com",
       }
    ]
    

    Optional

    ReadWrite

    entitlements

    Array of one or more entitlement values that this user has. Supported entitlement values are:

    • allow_smartcard

    • allow_mobile_id

    If no entitlements are provided the default settings for the Tenant takes effect.

    Code Block
    "entitlements":[
       {
          "value":"allow_smartcard",
          "value":"allow_mobile_id"
       }
    ]
    

    Optional

    ReadWrite

    active

    A Boolean value indicating whether a user is active. Only active users is supported.

    Code Block
    "active": true

    Optional

    ReadOnly

    UPN

    Field

    Description

    Example

    Required

    Mutablitity

    upn

    The name of the user in email address format

    Code Block
    "upn" : "user@example.com"

    Optional

    ReadWrite

    API Access Token

    Oppgis for BAS-Brukersted når det er avtalt bruk av scim for provisjonering.