Page Comparison

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 - Access SCIM API

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/DNR, fornavn, etternavn (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 

  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

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.

Batch preregistrering i BAM v 3.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.

I Notepad ser filen slik ut:

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. 
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 tall

E-post er valgfritt, og kan utelates. De fleste bedrifter bruker UPN og registrerer ikke "offisielle" e-post i AD. BAM-klienten er derfor ikke 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.

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 v 3.7.6

1. 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.

2. 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.
   

3. 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.
   

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 endret. Vi støtter ikke lenger .CSV-format, men har innført støtte for .JSON og .XML format.

1. Brukernavn/IssuersKey (obligatorisk)

2. FNR/DNR, fornavn, etternavn (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 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.

Preregistration filstruktur med XML / JSON

XML

<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

[
 {
   "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...
 }
]

Preregistrering med bruk av 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 

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.

"userName" : "01026201590"

Required

Immutable

externalId

An identifier for the User as defined by the customer

"externalId": "701984"

Required

ReadWrite

name

The user's real name

"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

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

Optional

ReadWrite

emails

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

"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.

"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.

"active": true

Optional

ReadOnly

UPN

Field

Description

Example

Required

Mutablitity

upn

The name of the user in email address format

"upn" : "user@example.com"

Optional

ReadWrite

API Access Token