NO318842B1 - Autentisering og tilgangskontroll - Google Patents
Autentisering og tilgangskontroll Download PDFInfo
- Publication number
- NO318842B1 NO318842B1 NO20021341A NO20021341A NO318842B1 NO 318842 B1 NO318842 B1 NO 318842B1 NO 20021341 A NO20021341 A NO 20021341A NO 20021341 A NO20021341 A NO 20021341A NO 318842 B1 NO318842 B1 NO 318842B1
- Authority
- NO
- Norway
- Prior art keywords
- user
- certificate
- service
- access
- authorization
- Prior art date
Links
- 238000010200 validation analysis Methods 0.000 claims abstract description 104
- 238000013475 authorization Methods 0.000 claims abstract description 93
- 238000000034 method Methods 0.000 claims abstract description 62
- 238000005516 engineering process Methods 0.000 claims abstract description 9
- 238000004891 communication Methods 0.000 claims description 18
- 230000004044 response Effects 0.000 claims description 14
- 238000012546 transfer Methods 0.000 claims description 9
- 238000013519 translation Methods 0.000 claims description 3
- 102000036364 Cullin Ring E3 Ligases Human genes 0.000 description 53
- 108091007045 Cullin Ring E3 Ligases Proteins 0.000 description 53
- 238000012545 processing Methods 0.000 description 33
- 230000008569 process Effects 0.000 description 13
- 230000007246 mechanism Effects 0.000 description 10
- 238000007726 management method Methods 0.000 description 9
- 238000013507 mapping Methods 0.000 description 7
- 239000000284 extract Substances 0.000 description 5
- 230000009471 action Effects 0.000 description 4
- 230000010354 integration Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 239000000047 product Substances 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- SVTBMSDMJJWYQN-UHFFFAOYSA-N 2-methylpentane-2,4-diol Chemical compound CC(O)CC(C)(C)O SVTBMSDMJJWYQN-UHFFFAOYSA-N 0.000 description 1
- 206010019233 Headaches Diseases 0.000 description 1
- 235000006508 Nelumbo nucifera Nutrition 0.000 description 1
- 240000002853 Nelumbo nucifera Species 0.000 description 1
- 235000006510 Nelumbo pentapetala Nutrition 0.000 description 1
- 101100382348 Streptomyces vinaceus vioD gene Proteins 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 235000014510 cooky Nutrition 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000012854 evaluation process Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 231100000869 headache Toxicity 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012011 method of payment Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008450 motivation Effects 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 230000014616 translation Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computing Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Denne oppfinnelsen omhandler generelt autentisering, autorisering, og tilgangskontroll, og mer spesifikt en metode og et system for generell Public Key Infrastructure basert på autentisering som tillater brukerne å ha kun én elektronisk ID for sikker tilgang til alle tjenester. Systemet beskrevet overgår dagens teknologi ved å tilveiebringe generell, PKI-basert autentisering. Ved å tilby validering og muligens også autoriseringstjenester til andre tjenestetilbydere, kan systemet tilveiebringe en infrastruktur for generell, PKI- basert autentisering, og håndtering av elektroniske ID'er fra i prinsippet enhver utgiver av slike.
Description
Denne oppfinnelsen omhandler generelt autentisering, autorisering, og tilgangskontroll, og mer spesifikt en metode og et system for generell PKI (Public Key Infrastructure) basert på autentisering som tillater brukere å ha bare én elektronisk ID for sikker tilgang til alle tjenester.
Bakgrunn for oppfinnelsen
Autentisering, autorisering, og tilgangskontroll er tre områder som er essensielle for
de fleste (kommunikasjons) tjenestetilbydere. De eneste unntakene er totalt åpne tjenester og anonyme betaling-pr.-bruk tjenester. Denne spesifikasjonen dekker den normale situasjonen, hvor navngitte brukere blir autorisert for bruk av spesifikke tjenester. Ved vellykket autentisering, blir en bruker gitt tilgang til disse tjenestene, underlagt tilgangskontrollprosedyrer.
Dagens autentiseringsløsninger ovenfor ISP (Internet Service Provider) eller andre tilbydere av IP-baserte (Internet Protocol) kommunikasjonsinfrastruktur er hovedsakelig basert på brukernavn og passord. RADIUS (Remote Authentication Dial-In Service) protokoll (og andre protokoller som TACACS+ (Terminal Access Controller Access Control System)) tilveiebringer tilgang til tjenester som tilveiebringer sentralisert administrasjon og vurdering av både
autentiseringsinformasjon og av autoriseringer som er tilegnet til (autentisert), brukernavn. Arbeidet i IETF (Internet Engineering Task Force) er pågående for "
neste generasjon av slike protokoller gjennom Diameterarbeidsgruppen.
Vanligvis må brukeren ha et separat passord for hver tjeneste. Passordbasert autentisering blir komplisert etter som flere og flere tjenester er tilveiebrakt, spesielt siden hver tjeneste vanligvis trenger en separat passordautentisering. For å håndtere denne kompleksiteten, velger vanligvis brukere passord som er lett å huske, og bruker det samme (brukernavn og) passord igjen og igjen.
Ettersom flere verdiskapende tjenester blir tilbudt over Internett, er det viktig å gi brukerne åpen PKI-basert (Public Key Infrastructure) brukerautentisering for å
erstatte kompleksiteten og svakhetene til passordbasert autentisering, beskytte brukeren mot tyveri av tjenester, og forenkle påloggingsprosedyrene (én elektronisk ID for tilgang til alle tjenester). Sterk autentisering vil også være nødvendig for å beskytte kunder og tjenestetilbydere mot svindel.
Det nyeste på PKI-området har fremdeles ikke dette generaliseirngsnivået.
Istedenfor står nå ofte brukerne overfor bruk av ulike PKl-løsninger (i stedet for
ulike brukernavn og passord) for tilgang til ulike tjenester. Det er dessuten ikke mange tjenester som nå er «PKI-muliggjorte», selv om denne funksjonaliteten kan være latent for mange tjenester i form av SSL/TLS (Secure Socket Layer/Transport Layer Security) klientautentiseirngsprosedyrer. Systemet beskrevet overgår det
nyeste på området ved å tilveiebringe generell, PKI-basert autentisering. Ved å tilby
validering og muligens også autoriseringstjenester til andre tjenestetilbydere, kan systemet tilveiebringe en infrastruktur for generell, PKI-basert autentisering.
Publikasjonen EP-1 175 038 beskriver en løsning for å fremskaffe et sertifikat ved bruk av en PKI-løsning. Ifølge denne løsningen genereres to sertifikater, hvorav ett er et "single sign-on certificate" med kort levetid, som øyensynlig representerer brukerens rettigheter. Publikasjonen kan ikke sees å beskrive et system der brukeren kan benytte et i prinsippet hvilket som helst sertifikat, herunder et sertifikat som ikke er generert av systemet selv.
. Sammendrag av oppfinnelsen
I samsvar med den foreliggende oppfinnelse er det oppnådd et system for tilveiebringelse av sikker tjenestetilgang for en bruker til i det minste én tjeneste fra en tjenestetilbyder, som angitt i det etterfølgende patentkrav 1.
Videre i samsvar med den foreliggende oppfinnelse er det oppnådd en fremgangsmåte for å tilveiebringe av sikker tjenestetilgang for en bruker til i det minste én tjeneste fra en tjenestetilbyder, som angitt i det etterfølgende patentkrav 10.
Ytterligere fordelaktige utførelsesformer fremgår av de uselvstendige krav.
Spesifikasjonen beskriver en forbedret løsning for autentisering, autorisering og tilgangskontroll ved bruk av sertifikater og PKI-teknologi, såvel som muliggjøringsmekanismer for betalingstjenester tilveiebrakt over datamaskinnettverk. Hovedfordelene med PKI-løsning er generalitet, skalabilitet, og, økt funksjonalitet (nøkkelhåndtering for kryptering, digital signatur). I fremtiden bør en bruker ha én nøkkelbeholder (f.eks. smartkort) inneholdende private nøkler og sertifikater som danner brukerens elektroniske ID. En elektronisk ID består vanligvis av to eller flere forskjellige private nøkkel/sertifikatpar for ulike formål. De fleste løsningene bruker to par, ett for kryptering (som kun tillater backup av denne spesielle private nøkkelen) og et annet for alle andre formål. Det er ofte anbefalt å tildele den digitale signaturfunksjonen til et separat, tredje par, men dette har ikke oppnådd utstrakt støtte i produkter eller tjenester.
Brukeren bør kunne velge utgiver av elektronisk ID (sertifikattjenestetilbyder). Tjenestene som brukeren ønsker å aksessere bør ikke umyndiggjøre bruk av spesifikke sertifikattilbydere. En bruker må uavhengig kunne få så mange elektroniske ID'er som ønskelig.
1 dag kan tjenestetilbydere som bruker PKI-basert autentisering av brukere typisk
akseptere sertifikater fra kun én av et fåtall sertifikattilbydere. Siden sertifikattjenester er forskjellige, må sertifikattilbydere i noen utstrekning integrere
separat mot alle tilbyderne. Dette blir fort for komplekst til å være brukbart, når sertifikater fra mer enn noen få tilbydere skal bli akseptert.
Samtidig er det i det minste flere hundre offentlige sertifikattilbydere i verden, og det kommer flere til. En tjenestetilbyder kan også ønske å akseptere sertifikater fra ulike selskapsinterne sertifikattjenester (som normalt er for intranettbruk).
Arkitekturen beskrevet separerer kompleksiteten av integrering mot et flertall av sertifikattilbydere til dedikerte komponenter, for derved å fjerne denne . kompleksiteten fra tjenesten i seg selv. En.bruker må registrere den elektroniske ID'en (dvs. sertifiktatet(ene)) som brukeren ønsker å bruke. Navnet på sertifikatet, og andre karakteristikker som dets kvalitetsnivå, er linket til brukerens service- eller tjenesteprofil.
Serviceprofilen er vedlikeholdt på en enkelt plass. Enkelte tjenester kan kreve en høykvalitets elektronisk ID for å tillate tilgang.
Navnet på sertifikatet trenger ikke å være brukerens faktiske navn. Avhengig av politikk, kan dette være et pseudonym, rollenavn, organisasjonsidentitet, abonnementsnavn, osv.
Ved å bruke den elektroniske ID'en kan en bruker til slutt logge på et nettverk og oppnå tilgang til alle tjenester som brukeren abonnerer på. Systemet beskrevet kan tilveiebringe enkel pålogging mot tjenester som er forberedt for dette. Mot tjenester som trenger deres egen autentisering, er fortreffeligheten av systemet at brukerens elektroniske ID kan bli brukt på nytt, i stedet for å måtte opprettholde et forskjellig passord for hver tjeneste. Brukeren må.autentisere flere ganger men bruker samme metode alle gangene. Dette er avhengig av tilgjengeligheten av den beskrevne valideringstjenesten, og i noen utstrekning også til autentiseringstjenesteh.
Fleksibiliteten til dette systemet muliggjør også at brukerne kan bruke operativsystem- fritt. Software for elektroniske ID-løsninger er ofte plattformavhengig. Med en åpen PKI-løsning, kan brukeren velge en elektronisk ID, som kan bli støttet av det ønskede operativsystemet.
Kredittkortselskaper begynner å kreve brukerautentisering for betalinger over Internett, og passordautentisering vil bare være akseptabel i det korte løp. Etablering av generell PKI vil tillate at kredittkortselskapene aksepterer elektronisk ID som allerede eies av brukeren (forutsatt at det kvalifiserer) istedenfor å måtte utgi separat elektronisk ID for bruk for å gjøre betalinger.
Systemet beskrevet vil tilveiebringe midler for sikker autentisering, autorisering, og tilgangskontroll for verdiøkende tjenester slik som video på etterspørsel (Video on Demand, VOD) såvel som tilveiebringelse av midler for sikker betaling.
Denne oppfinnelsen omhandler generelt autentisering, autorisering, og tilgangskontroll, og mer spesifikt en metode og et system for generell Public Key Infrastructure basert autentisering som tillater at brukerne kan ha kun én elektronisk ID for sikker tilgang til alle tjenester. Systemet beskrevet overgår det nyeste på området ved å tilveiebringe generell, PKI-basert autentisering. Ved å tilby validering og muligens også autoriseringstjenester til andre tjenestetilbydere, kan systemet tilveiebringe en infrastruktur for generell, PKI-basert autentisering.
Beskrivelse med henvisning til tegningene
Oppfinnelsen skal nå bli beskrevet med henvisning til medfølgende tegninger hvor: Fig. 1 viser oversikten over autentisering og autoriseringsarkitekturen; Fig. 2 viser en alternativ metode for å sjekke validiteten til et brukersetrifikat; Fig. 3 viser et flytskjema for autentisering, autoriseringssjekking og tjenestetilgangsprosessen;
Fig. 4 viser tilgang til verdiøkt tjeneste; og
Fig. 5 viser en oversikt over valideringstjenesten.
Fig. 1 viser systemarkitekturen i henhold til oppfinnelsen. Brukeren blir autentisert, typisk ved SSL/TLS klientautentisering, og gitt tilgang, på tilgangsserveren, til et nettgrensesnitt med en meny for abonnementssettet med tjenester. Kommunikasjonen mellom klient og tilgangsserver må være krypteringsbeskyttet. SSL/TLS er det foretrukne valget, siden dette er den vanlige måten å beskytte nett (HTTP) kommunikasjon, og kan inkorporere brukerautentisering. En løsning basert på IPSec/VPN (Internet Protocol Security/Virtual Private Network) mellom de to delene kan være et alternativ.
Autentiseringsprotokollen anvendt (som SSL/TLS med både klient- og serverautentisering) identifiserer underforstått brukeren ved navnet i brukerens sertifikat, som blir sendt over til tilgangsserveren som en del av protokollen. Brukeren må også bruke korresponderende privatnøkkel for å signere en utfordring/responssekvens som beviser besittelse av den private nøkkelen.
Gitt brukerens sertifikat og signatur, kan tilgangsserveren ferdigstille brukerens autentiseringsprosess. Imidlertid er, når utført skikkelig med tilbakekallings (eng: revocation) sjekking og på en måte som tillater ulike sertifikater fra ulike sertifikattilbydere, sertifikatvalidering en for tung prosess for kjøring på hver tilgangsserver. I arkitekturen er en separat komponent, valideringstjeneste, introdusert for å være ansvarlig for (og belaste) for (deler av) sertifikatprosesseringen. Valideringstjenesten kan bli duplisert dersom nødvendig. Til slutt kan tilgangsserveren rett og slett trekke ut brukerens sertifikat og sende den av gårde til valideringstjenesten. Svaret er et ja/nei svar på sertifikatets gyldighet, dets kvalitetsnivå (som kan være relevant med hensyn til autorisasjoner som kan bli gitt), brukernavnet, som blir utledet fra navnet i brukerens sertifikat, og muligens mer informasjon dersom ønskelig. Imidlertid, må en også dele lasten mellom tilgangsserver og valideringstjenesten forskjellig, dvs. ved å utføre flest sertifikatprosesser lokalt på tilgangsserveren, og etterlate hovedsakelig den (normalt ressurskonsumerende) oppgaven med tilbakekallingssjekking til valideringstjenesten.
Brukerens profil bør bli holdt på én plass, dvs. autoriseirngstjenesten. Kartleggingen av en brukers sertifikatnavn til korresponderende brukernavn er en del av profilen, og dermed kaller valideringstjenesten opp autoriseringstjenesten for å oppnå denne kartleggingen etter å ha-trukket ut navnet fra sertifikatet. Alternativt kan valideringstjenesten returnere sertifikatnavnet til tilgangsserveren, som da kan utføre navnkartleggingen ved et separat kall til autoriseringstjenesten. I dette tilfellet, er det ingen grensesnitt mellom valideringstjenesten og autoriseringstjenesten.
Fig. 2 viser et flytskjema av autentisering, autoriseringssjekking og tjenestetilgangsprosess. Flere protokoller kan bli brukt mot valideringstjenesten. Dersom valideringstjenesten skal bli tilbudt til tjenestetilbydere som en separat tjeneste, så må protokollen være av standard type. OCSPvl (On-line Certificate Status Protocol, version 1) er et alternativ som gjør det mulig å sjekke tilbakekallingsstatus til et sertifikat og returnere noe tilleggsinformasjon, som et brukernavn. Imidlertid er det ofte ikke mulig å sende over et komplett sertifikat til valideringstjenesten på en standardisert måte, men bare bruke en ikke-spesifisert «utvidelse». OCSPv2 er en avansert utkast RFC, og vil tilveiebringe muligheten for å sende et komplett sertifikat. SCVP (Simple Certificate Validation Protocol) har den samme statusen som OCSPv2, og tilveiebringer den samme funksjonaliteten. XKMS (XML Key Management Service) er et annet alternativ, som i andre XML-baserte mekanismer, f.eks. ved å bruke SOAP (Simple Object Access Protocol).
i
Gitt en autentisert brukeridentitet, forespør så tilgangsserveren autoriseringstjenesten om tilgangsrettigheter som den navngitte brukeren skal bli tillatt. Forespørselen kan bli utvidet ved tilleggsinformasjon som kvaliteten til brukerens autentiseringsprosedyre, og kontekstinformasjon som brukerens nåværende lokasjon, tid på dagen etc. Tilgang til autoriseringstjenesten bør være basert på standardprotokoll, som kan være LD AP (Lightweight Directory Access Protocol), RADIUS, sin planlagte etterfølger DIAMETER, eller en annen protokoll.
Det er også mulig å delegere oppslag mot autoriseringstjenesten til valideringstjenesten. I dette tilfellet vil tilgangsserveren utføre kall bare til valideringstjenesten, og få tilbake både brukernavn og annen informasjon relatert til autoriseringsprosedyren som beskrevet over, og autoriseringer som brukeren skal bli innvilget.
Etterfølgende denne prosedyren, vil brukeren bli presentert med riktig tjenestemeny. Tjenestevalg er det neste trinnet som beskrevet under.
Flytskjemaet i fig. 2 viser trinnene som blir tatt i autentisering, autoriseringssjekking og tjenestetilgangsprosedyrer.
I det følgende vil en typisk oppkoblingsoppsett og tilgang til tjeneste bli beskrevet. Brukerens utstyr eller hjemmenettverk blir forbundet til infrastrukturen tilbudt av nettverksoperatøren via en form for tilgangspunkt, som typisk tilveiebringer protokoller ved datalink eller tilgangslaget, og nettverkslaget, dvs. IP-protokollen. Tilgangspunktet er ikke vist i fig. 1, ettersom det bare opptrer som en ruter med hensyn til nett-tilgang fra brukeren til tilgangsserveren. Tilgangspunktet kan bli separert inn i to komponenter: én som tilbyr tjenester ved datalink/tilgangslaget, og en annen som er en IP-ruter.
Når brukerutstyr kobles til nettverksinfrastrukturen, er det typisk gitt tilgang til et default, minimumssett av tillatte kommunikasjonsstier. I arkitekturen vist, må ruten mot tilgangsserveren bli gjort tilgjengelig, og vanligvis må også en Domain Name Service (DNS) også bli gjort tilgjengelig. Videre tjenester/stier kan bli lagt til til denne minimale konfigurasjonen.
Når brukeren åpner en nettleser på brukerens utstyr, må denne bli rettet til URL til tilgangsserveren for at brukeren skal få tilgang til tjenestene. Brukeren må så gå gjennom autentiseringsprosedyren og autoriseringssjekker, og vil bli gitt tilgang til tjenestemenyen.
Det er primært tre typer tjenester tilgjengelige: kommunikasjonstjenester, nettbaserte tjenester, og mediatjenester innbefattende multimedia. Den tredje kategorien kan bli beskrevet som en kombinasjon av de andre to. Handlingene utført for hver av disse kategoriene blir beskrevet i det følgende.
Kommunikasjonstjenester: Når brukeren velger en kommunikasjonstjeneste, må denne forespørselen bli formidlet til brukerens tilgangspunkt, for å kunne være i. stand til å rute mot bestemmelsesstedet valgt. Ruten kan bli muliggjort ved IP-laget, som åpner opp for trafikk fra brukerens (utvalg) IP-adresse(r) til et visst (utvalg) - . bestemm els esst ed(er). Denne ruten kan også bli muliggjort via datalinklaget, dvs. ved etablering av en ATM (Asynchronous Transfer Mode) virtuell krets.
Ett eksempel på kommunikasjonstjeneste kan være generell internett-tilgang gjennom en ISP. Valg av internett-tilgang i tjenestemenyen vil muliggjøre en rute fra brukeren til ISP'ens tilgangsnode (grenseruter), fra hvilket tilgang kan fortsette. Tilgangsserveren trenger å formidle de riktige kommandoene til brukerens tilgangspunkt for å muliggjøre den forespurte kommunikasjonstjenesten. Flere protokoller kan være brukt til dette formålet, med RADIUS som det mest vanlige alternativet. DIAMETER er den planlagte etterfølgeren til RADIUS.
Det finnes tre forskjellige scenarier for brukertilgang til nettbaserte tjenester fra tjenestemenyen til tilgangsserveren.
I det første scenario, formidler tilgangsserveren direkte tilgang til tjenesten i en enkel påloggingsmåte, ved å sende over et enkelt påloggingsmerke (eng: token) til tjenesten. I den enkleste formen, er dette et brukernavn og passordet til tjenesten til en HTTP Post operasjon, for derved å logge brukeren transparent til tjenesten. Brukeren blir så enten omdirigert til tjenesten, eller tilgangsserveren fortsetter operasjonen som en HTTP-proxy mellomledd. Det finnes flere produkter og teknologier for enkel pålogging tilgjengelig, og merker fra slike teknologier kan bli brukt. Tilgangsserveren kan muligens også skrive en «cookie» til brukerens nettleser, som vil bli gjenkjent og akseptert som et enkelt påloggingsmerke når . brukeren tar direkte tilgang til tjenesten. Tjenesten kan ha tilgang til autoriseringstjenesten, f.eks. for å sjekke flere detaljerte privilegier relatert til tjenestebruken.
I et annet scenario, blir tjenesten tilbudt innenfor domenet av systemer beskrevet, men trenger en separat autorisering. Brukerens elektroniske ID (privat nøkkel og sertifikat) blir brukt mot tjenesten, dvs. brukeren har en enkel mekanisme. Tjenesten har tilgang til valideringstjenesten, og kan også bruke autoriseringstjenesten.
I et tredje scenario, blir tjenesten tilbudt på utsiden av domenet til systemet beskrevet. Dersom tjenesten blir muliggjort for slik autentisering, så kan brukerens elektroniske ID (privatnøkkel og sertifikat) bli brukt, dvs. brukeren har en enkel mekanisme. Tjenesten har tilgang til valideringstjenesten, men siden den ikke er i systemets domene, vil den ikke vanligvis ha tilgang til autoriseringstjenesten.
Valideringstjenesten er generell, som kan, bli tilbudt til samarbeidende selskaper både på innsiden og utsiden av systemets domene. Valideringstjenesten kan bli konfigurert for å returnere ulik informasjon (f.eks. ulike brukernavn) avhengig av tjenesten som kaller den opp. Dette er et direkte resultat av den generelle naturen til PKI-basert autentisering. En kan ikke tillate denne form for tilgang av. passordbasert autentisering, siden passord vil bli vist til eksterne selskaper.
Autentiseringstjenesten bør imidlertid normalt bare være aksesserbar innenfor domenet til systemet. Å tillate eksterne selskaper tilgang til domeneintern autoriseringsinformasjon eller også å håndtere autoriseringsinformasjon gjennom samme tjeneste vil i de fleste tilfellene ikke være akseptabelt. Media/multimediatjenester: Som sagt kan (multi-)mediatjenester bli betraktet som en kombinasjon av kommunikasjonstjenester og nettbaserte tjenester. Noen mediatj en ester kan bli implementert i sin helhet på nettbaserte eller kommunikasjonstjenester, men det vanlige scenariet er en tjeneste som
tilveiebringer et nettbasert'grensesnitt for tjenesteoppsett, og en tjenesterealisering som stoler på funksjonaliteten i nettverket. Dersom tilgangsserveren opptrer som en proksy mellom brukeren og mediatj enesten, kan den fange opp kommunikasjon og utføre støttehandlinger som initiering av en VPN mellom dem, eller tilveiebringe informasjon til en «multicast membership system».
Fig. 3 viser en alternativ måte å sjekke valideringen til et brukersertifikat. Istedenfor å sende brukerens sertifikatnavn til en autoriserings tjeneste, blir det sendt til en tilgangsserver, som i tur mottar den navngitte brukeridentiteten fra
autoriseringstjenesten.
Fig. 4 viser et eksempel på autentisering, autorisering, og tilgang til en verdiøkende
tjeneste slik som Video on Demand (VOD) såvel som sikker betaling (på en betaling pr. bruk basis).
Brukeren blir autentisert ved å bruke auténtiseringsarkitektur beskrevet i fig. 1. Innholdet blir beskyttet ved kryptering under hele varigheten av sesjonen, og betaling blir sikret på en betaling pr. bruk basis. Innholdet kan bli dekryptert ved å bruke brukerens nøkler tilveiebrakt av den elektroniske ID'en. Brukeren kan velge en metode for betaling f.eks. faktura eller kredittkort, og signere transaksjonen ved å bruke den elektroniske ID'en brukt for autentisering. Alternativt kan brukeren velge en ekstern mekanisme som skal brukes for betaling og sikring av
transaksjonen.
Oppfinnelsen vil nå bli beskrevet i mer detalj med henvisning til fig. 2. Tilgangsserveren opptrer som brukerens tilgangspunkt til tjenestene ved autentisering av brukeren, og tilveiebringelse av dem med passende tjenestemeny. For å utføre sin rolle i systemet må tilgangsserververen: - Støtte HTTPS (HTTP over SSL/TLS) eller alternativt være i stand til å tilveiebringe andre midler for sikre kommunikasjonskanaler; - Være i stand til å autentisere seg selv til klienter/brukere, fortrinnsvis ved bruk av PKI-teknologi (f.eks. SSL/TLS-serverautentisering); - Støtte protokollene som er nødvendig for å kommunisere med valideringstjenesten og autoriseringstjenesten; - Støtte én eller flere protokoller fra PKI-basert klient/brukerautentisering, vanligvis SSL/TLS med klientautentisering; - Implementere funksjonaliteten som er nødvendig for å fremvise nødvendig informasjon (slik som tjenestemeny) til brukeren, og håndtere brukerens innmating; - Være i stand til å opptre som en proksy mellom brukeren og tjenesten, dvs.
videreformidle informasjon som er transparent mellom dem.
Brukeren må rette nettleseren til nettgrensesnittet tilveiebrakt av tilgangsserveren for å kunne få tilgang til tjenestene. Normalt vil brukeren autentisere straks gjennom SSL/TLS med klientautentisering, som beskrevet over.
Det finnes to alternative metoder: Dersom en annen PKI-basert autentiseringsmetode blir brukt, kan en SSL/TLS-sesjon bli etablert med kun serverautentisering, og brukerautentiseringsprotokoll kan bli kjørt på denne sikre kanalen. Dersom flere alternativer eksisterer for autentiseringsmetode, kan brukeren bli vist en klar tekst (dvs. ren HTTP) side for valg av metode. Etter valget, fortsetter autentisering, f.eks. ved å etablere en SSL/TLS-sesjon med klientautentisering.
Som beskrevet stoler tilgangsserveren på å få brukerens sertifikat fra brukeren. Andre midler for å oppnå sertifikatet, f.eks. et registeroppslag, kan i tillegg bli implementert.
Sorri beskrevet i seksjonen under, når det gjelder valideringstjenester, bør så mye
. som mulig av lokal sertifiseringsprosessering bli koblet ut i tilgangsserveren, og etterlatt til valideringstjenesten i stedet. Tilgangsserveren må validere brukerens sertifikat ved hjelp av valideringstjenesten, verifisere brukerens signatur på anropsdelen til autentiseringsprotokollen, og opptre i henhold til suksess eller feiling av denne autentiseringen. Laging av anrop, og verifisering av signaturen på anropet, kan bli gjort eksternt til tilgangsserveren. Siden tilgangsserveren er eksponert til angrep fra brukeren, kan en ønske å bruke en mer beskyttet datamaskin for sikre kritiske operasjoner.
Den første handlingen etterfølgende brukerautentisering vil vanligvis være å hente brukerens tjenesteliste fra autentiseringstjenesten, dersom ikke denne allerede har blitt mottatt fra valideringstjenesten. Senere opptrer tilgangsserveren i henhold til brukerens innmating, i henhold til reglene som er i kraft, og i samarbeid med autoriseringstjeneste for handlinger som trenger sjekk mot brukerens profiler. Som beskrevet i fig. 1 kan en enkel påloggingsmekanisme bli implementert.
Valideringstjenesten er optimalisert for sertifikatprosessering. Den mottar et sertifikat, eller identifikasjon av sertifikat og dens utgiver, og:
- Leser navnet fra utgiveren.
- Henter utgiverens fellesnøkkel fra en for-evaluert liste av «gode» nøkler. Alle kryss-sertiifkatregimer eller hierarkier har blitt for-prosessert, og alle utgiverfellesnøkler blir direkte stolt på, dvs. ingen prosessering av sertifikatlenker er nødvendig. - Utføre tilbakekallingssjekker, fortrinnsvis ved lokalt oppkall til forprosessert tilbakekallingsinformasjon oppnådd av regulær for-henting av CRL
(certificate revocation list).
- Dersom det komplette sertifikatet har blitt mottatt, analysere sertifikatet, sjekke signatur og gyldighetsperiode og trekke ut innholdet. Dette må bli behandlet individuelt foT ulike sertifikatprofiler. - Trekker ut informasjon kartlagt fra sertifikatinformasjonen, som brukernavn utledet fra navn i sertifikatet, kvalitetsnivå (forhåndsbestemt basert på en analyse av sertifikatpolitikken), osv. Informasjonen kan være generell, eller spesifikt målrettet mot enheten som kalte opp for sertifikatvalidering.
Disse operasjonene kan bli optimalisert i valideringstjenesten, for å tilveiebringe de nødvendige, raske responstider. Spesielt pålegger prosessering av sertifikatkjeder og tilbakekallingssjekking normalt tung last på serveren. Av denne grunn er skikkelig tilbakekallingssjekking ofte undertrykket i dagens PKI-muliggjorte tjenester. Valideringsserveren stoler på for-prosessering av tilbakekallingsinformasjonen for å kunne få en raskere prosess.
Flere protokoller kan bli brukt mot valideringstjenesten. OCSP (On-line Certificate Status Protocol) versjon 1 er tilgjengelig i dag men har ingen standard måte å overføre et komplett sertifikat. OCSP versjon 2, som er under utvikling som et intemettutkast, legger til denne muligheten. Alternative protokoller som kan være et tillegg til eller erstatte OCSP, er SCVP (Simple Certification Validation Protocol), som er en internettutkastprotokoll og XKMS (XML Key Management System). Protokoller kan også være basert på SOAP (Simple Object Access Protocol, essensielt XML over HTTP) eller lignende teknologier, eller noen beskyttet protokoll kan bli designet. Alle disse protokollene tilveiebringer muligheten for å returnere tilleggsinformasjon til oppkalleren, sammen med ja/nei/ukjent svar til valideringsforespørselen selv.
OCSP er primært målsatt som en erstatning av CRL-utgivelse fra en sertifikatmyndighet. Istedenfor, eller i tillegg til, CRL, tilveiebringer sertifikatutgiveren et OCSP-grensesnitt som svarer på forespørsler om gyldigheten til sertifikatene kun utgitt av denne sertifikatmyndigheten. I vår kontekst, vil valideringstjenesten tilveiebringe en OCSP-tjeneste for alle sertifikatmyndighetene som er støttet.
OCSPvl beskriver tilbakekallingssjekking som den eneste funksjonaliteten til en OCSP-tjeneste. Dette er for snevert, og det er foreslått å forbedre denne. For det første bør valideringstjenesten ikke bare sjekke om sertifikatet har blitt tilbakekalt eller ikke, men også om det er innenfor gyldighetsperioden, og om utgiverens signatur på sertifikatet er riktig. Videre bør valideringstjenesten også analysere sertifikatet og handle overfor innholdet ved å bestemme kvalitetsnivået og brukernavnet, muligens også mer informasjon.
OCSP tilveiebringer klientautentisering og integritetsbeskyttelse av forespørsler ved muligheten av å la oppkalleren digitalt signere (deler av) forespørselen. Likeledes kan valideringsserveren også signere responsene. Dette kan bli implementert for andre protokollalternativer. Signerte responser kan være veldig viktig, siden falske eller manipulerte responser kan være en signifikant trussel. Signerte forespørsler kan være nødvendig for å kunne returnere oppringerspesifikk informasjon, dersom ikke oppringeren er autentisert på annen måte.
Imidlertid, siden signaturprosessering (som vanligvis også medfører sertifikatprosessering) er forholdsvis tidskonsumerende, det kan være bedre å sørge for at oppkall til valideringstjenesten blir gjort over en sikkeT kanal, f.eks. ved hjelp av en VPN-løsning. Dette bør definitivt være tilfelle for kanalen mellom en tilgangsserver og valideringsserver, muligens også fra andre domeneinterne tjenester mot valideringstjenesten. Dersom valideringstjenesten er tilveiebrakt mot eksterne selskaper, må tilveiebringelse av signerte forespørsler og svar være implementert, siden en sannsynligvis ikke kan erhverve VPN eller lignende for alle slike eksterne selskaper.
Det følgende dekker behovene på serverne som bruker valideringstjenesten. Spesielt er dette tilgangsserveren.
Særlig ligger en slik server på en tilgangsserver. For å kunne bruke valideringsserveren, bør (deler av) sertifikatprosesseringen være «kortsluttet» ved disse tjenestene. Noen scenarioer for prosessering i en server blir beskrevet i det følgende: - SSL-klientautentisering: SSL-prosessering ved serveren må trekke ut klientens sertifikat, og enten videreformidle disse til valideringstjenesten uten videre prosessering, eller utføre noen prosessering lokalt før videreformidling av det komplette sertifikatet eller informasjon utledet fra dette. Basert på svaret, vil SSL-oppsett enten fortsette eller avbryte. - Kvittering av en digitalt signert beskjed: Klientens (sender) sertifikat kan bli trukket ut fra beskjeden (eller oppnådd fra andre midler) og sendt til valideringstjenesten. Alternativt kan noen sertifikatprosessering bli utført lokalt før sertifikatet, eller informasjon utledet fra dette, blir sendt til valideringstjenesten. Etterfølgende en vellykket validering, kan signaturen av beskjeden selv bli verifisert lokalt. Valideringstjenesten kan også bli hevet til å håndtere alle signaturprosesseringer i systemet, på beskjed såvel som sertifikater. - Validering av et sertifikat som etterfølgende vil bli brukt for (nøkkelhåndtering for) kryptering av beskjeder eller kanaler mot en gitt motpart: Prosessering vil bli analog til mottak av sertifikat i en digitalt signert beskjed. - Etablering av en VPN: Prosessering vil bli omtrent nøyaktig som SSL-kl i entautenti seri ngsscenario. - Andre PKI-baserte autentiseringsprotokoller: Serveren må få klientens
sertifikat, og deretter kalle opp valideringstjenesten som indikert i scenarioet over, sertifikatprosessering kan enten bli gjort i sin helhet på valideringstjenesten, eller noen form for lokal prosessering kan bli utført.
For å implementere oppkallet (protokollalternativene listet over) til valideringstjenesten, er modifikasjoner til serversoftwaren nødvendig. Mengden av lokal prosessering som kan bli «kortsluttet» avhenger av modifikasjonene som er mulig for den spesifikke serverplattformen. For optimal ytelse, bør oppkall til valideringstjenesten bli innfelt med andre prosesseringer i serveren, og delvis eller fullt erstattet funksjonalitet (lokal sertifikatprosessering) som allerede er på plass i de fleste serverplattformer. Slike modifikasjoner blir vanligvis heller kompliserte,
og avhenger av åpenheten til plattformen. Alternativet er tillegg av ekstra funksjonalitet på topp av tilgjengelige, åpne grensesnitt, med lokal sertifikatprosessering kun kortsluttet i den utstrekning som er mulig av konfigurasjonsparameterne.
Det er også mulig å tilveiebringe brukergrensesnitt for brukere (klienter) mot valideringstjenesten. I dette tilfellet, er sertifikatprosessering i brukerens nettleser (typisk, kan også være annen software i brukerens utstyr) i sin helhet eller delvis erstattet av oppkall til valideringstjenesten i stedet for lokal
sertifiseringsprosessering. Den primære bruken av slike grensesnitt vil være prosessering av SSL-serversertifikater, men det brukes også relatert til VPN-
oppsett, mottak av digitalt signerte beskjeder, og validering av sertifikater som vil bli brukt for kryptering av beskjeder/trafikk mot motparter. I dette tilfellet, kan svar fra valideringstjenesten bli signert, og forespørsler fra brukeren kan bli signert. Dersom valideringstjenesten verifiserer signaturene på sertifikatet på vegne av brukeren, kan listen av (i dag rundt 150) sertifikattilbyder offentlige nøkler, som er for-konfigurert i standard nettlesere (og f.eks. i nyere Microsoft OS versjoner) bli fjernet fra brukerens utstyr. Brukerens håndtering av (og tillitt til) slike utgiveroffentlige nøkler er en hovedhindring for PKI-bruk.
Med hensyn til støtte for forskjellige sertifikatutgivere, er det to grunnleggende
idéer bak introduksjonen av valideringstjenesten:
- Effektivitet, ved optimalisering av tjeneste for sertifikatprosessering,
spesielt ved å kvitte seg med prosessering av sertifikatkjeder og ved å sjekke tilbakekalling av et lokalt databaseoppslag i stedet for CRL-prosessering.
- Tilveiebringelse av et enkelt punkt med integrering for tjenester som
ønsker å akseptere sertifikater fra mer enn én sertifikatutgiver.
I dag må tjenester som bruker PK.I-basert autentisering integrere individuelt mot
hver sertifikatutgiver som de ønsker å godta sertifikater fra. Integreringskompleksiteten spesielt har å gjøre med forskjellige sertifikatformater, forskjellige navnskjemaer, ulike tilgangspunkter for tilbakekallingsinformasjon, og
håndtering av utgivers offentlige nøkler. En tjeneste kan dermed bare integrere med et fåtall av valgte sertifikatutgivere direkte. Valideringstjenesten fjerner denne kompleksiteten fra tjenestene.
Imidlertid", har selv valideringstjenestene et kompieksitetsproblem når mange sertifikatutgivere skal bli støttet. Hovedkompleksiteten er å bestemme kvalitetsnivået, som forklart i det neste avsnittet. Håndtering av offentlige nøkler av utgivere må være pålitelig og kontinuerlig overvåket for tilbakekalling og andre oppdateringer. Sertifikatformater fra ulike utgivere må det redegjøres for ved spesifikke analyser (selv om standardiserte profiler i noen grad muliggjør denne oppgaven; men en trenger å bestemme profilen som er forespurt). Valideringstjenesten er ikke for komplisert fra et teknisk synspunkt, men håndtering av tjenesten trenger ressurser. Imidlertid er det i mange sammenhenger bedre å sentralisere denne kompleksiteten i stedet for å måtte håndtere den for hver eneste tjeneste separat.
Dette peker på spørsmålet om hvor mange, og hvilke sertifikatutgivere en ønsker å . støtte gjennom tjenesten. Flere hundre offentlige sertifikatutgivertj enester eksisterer
rundt om i verden, med flere etterfølgende. I tillegg vil en finne økende samarbeidende (intranett) systemer, som kan være basert på standardprodukter fra f.eks. Microsoft eller IBM/Lotus som tillater enhver å etablere en sertifikatutgivende tjeneste. Mens de fleste av disse tjenestene vil oppnå svært dårlig kvalitet og tillitt, f.eks. utgitt uten å være understøttet av en målsetning og i store trekk ubrukelig utenfor selskapets intranett, kan situasjoner oppstå hvor en
ønsker å være i stand til å akseptere sertifikater fra et samarbeidende selskap eller samarbeidende kunde.
Bestemmelsene rundt dette spørsmålet har mer en håndterings- enn en teknisk natur, så lenge som valideringsservertj enest ens implementasjonsskaleringsegenskaper er tilstrekkelige.
En viktig nødvendighet er at sertifikatet må tilveiebringe, direkte eller indirekte, informasjonen som er nødvendig for videre prosessering, særlig et navn som kan bli brukt for tilgangskontroll og regnskap.
Med hensyn til kategorisering av sertifikater og kvalitetsnivåer, er en sertifikatutgivende tjeneste definert av de følgende komponentene: - Lovrammeverk og avtaler; - Sertifikat politikk, som tilveiebringer behov for prosedyrer relatert til tjenesten, og vanligvis dekker mange av aspektene til lovrammeverket og avtalene, (som imidlertid ofte må gjøres eksplisitt, og dermed garanterer et separat punkt); - Sertifikatpraktiserende uttalelse, som forklarer hvordan behovene til politikken blir møtt ved denne spesifikke sertifikatutgivertj enesten - kan referere til interne prosedyredokumenter; Sertifikatformater, spesielt navnkonvensjoner; - Pålitelighetsmodeller mot andre aktører, og spesielt holdning mot hierarkistrukturer og kryss-sertifikatregimer; - Informasjon/registertjenester for sertifikater, tilbakekallingsinformasjon, politikkinformasjon og annen relevant informasjon.
Kvalitetsaspekter av sertifikattjeneste blir i hovedsak utledet fra sertifikatpolitikken. Politikken markerer behov for registreringsprosedyren som en bruker må gå gjennom for å oppnå sertifikatet (f.eks. elektronisk søknad kontra personlig tilstedeværelse med fysisk autentisering, etc.), forpliktelser som brukeren er enig i å påta seg dersom feil oppstår, sikkerhetsbehov pålagt på opereringen av tjenesten, osv. Heldigvis finnes det et fåtall standard rammeverk for å skrive fremgangsmåtepolitikk (eng: policies), og de fleste sertifikatutgiverne holder seg til
én av disse. Sertifikatfremgangsmåtepolitikker kan derfor bli sammenlignet punkt for punkt.
Imidlertid er kategorisering av sertifikatfremgangsmåtepolitikker en stor manuell oppgave som trenger noe ekspertise. Det er et behov for et kategoriseringskriterium og en metodisk fundamentering for kategoriseringen. Hvilket kriterium må bli tilfredsstilt for å nå et spesifikt kvalitetsnivå? Legg til videre kompleksiteter som fremgangsmåtepolitikker skrevet på et utenlandsk språk, og referer til lover og reguleringer fra utlandet. Dersom ikke noen kommer opp med en uavhengig tjeneste for kategorisering/klassifisering av fremgangsmåtepolitikker, er en tvunget til å gå
gjennom evalueringsprosesser uavhengig for alle utgiverne. Dette betyr at en må starte med et fåtall av viktige utgivere, og utvide dette senere etter behov.
Uavbrutt overvåkning av de støttede fremgangsmåtepolitikkene må bli utført. Imidlertid vil vanligvis politikkene beskrevet forandre prosedyrene, og mange utgivere vil støtte aktive notifikasjoner på andre selskaper dersom det finnes store forandringer i fremgangsmåtepolitikkene.
En kvalitétskategorisering kan kun være en enkel nummerisk verdi, f.eks. 1-4 med 1 som toppnivå og 4 som dårlig kvalitetsnivå. Det har vært svært lite arbeid på standardisering av slike nivåer. Innenfor EU, har «kvalifisert sertifikat» nivå blitt (mer eller mindre) etablert som en høykvalitetsindikator som støtter formelle digitale signaturer. I USA definerer «federal bridge certificate authority» noen kvalitetsnivåer. En sertifikatutgiver som tilveiebringer tjenester mot den føderale sektoren bør kryss-sertifisere med broen som indikerer en fremgangsmåtepolitikk-kartlegging mellom sin egen politikk og det passende kvalitetsnivå som definert av broen. ETS I arbeider nå på et «ikke-kvalifisert politikkrammeverk», som vil definere noen indikatorer som bør tas hensyn til ved kategorisering av fremgangsmåtepolitikk.
Kvalitetskategorisering kan også bli mye mer fingradert enn bare en nivåindikator. Basert på politikkrammeverket og ETSI's foreliggende arbeid, kan noen parametere bli utledet fra fremgangsmåtepolitikken inn i en struktur som kan bli returnert til oppkalleren. Som et eksempel har ansvaret som en sertifikatutgiver er villig til å ta en påvirkning på verdien av transaksjonene som kan bli understøttet av en autentisering basert på sertifikatet fra utgiveren. Domsmakten indikert av fremgangsmåtepolitikken er en annen viktig parameter.
Bemerk at en annen sak er om kvalitetsnivået (politikken og relatert praksis) kun
blir krevd av sertifikatets utgiver, eller om kravet er understøttet av tredjeparts bevis. Mange sertifikatpolitikker krever tredjeparts revisjon av tjenester, for å sørge for at faktisk operasjon er i henhold til fremgangsmåtepolitikken, praktiske
redegjørelser, og interne prosedyrer. Slike revisjonsrapporter vil sannsynligvis medføre en høyere kvalitetsrate, eller i det minste mer sikkerhet rundt ratingen.
Sertifikater som ISO9000 eller ISOl 7799 vil også telle her.
Bemerk til slutt af kvaliteten på tjenester ikke nødvendigvis medfører troverdighet. Det (tenkte) «Mafia CA» kan oppnå en kvalitetsrating, men det er fremdeles ikke klart om dets sertifikat bør bli akseptert.
I tillegg til sertifikatfremgangsmåtepolitikk og kvalitetsnivå, må andre aspekter til sertifikatutgivende tjeneste bli tatt hensyn til. Spesielt må en pålegge behov på sertifikatformatene, som spesifikke felt, egenskaper eller utvidelser som må være
tilstede, eller som ikke skal være tilstede. Navngivning er en separat sak, og for systemene som er definert i dag, må det være mulig å oversette fra navnet i
. sertifikatet til et gyldig brukernavn. Et annet behov som kan komme frem i noen" tilfeller er at brukernavnet må være «reelt», og ikke et pseudonym. Fig. 5 viser foreslått arkitektur av valideringstjenesten. Det består av de følgende delene: - En OCSP-server som prosesserer syntaks og semantikk relatert til denne protokollen. Videre frontmaskiner fra.andre protokoller kan bli lagt til senere, indikert som stiplede linjer. - En valideringsmaskin som prosesserer sertifikatene, sjekker gyldighet og utleder informasjon. - En separat prosess for for-henting og prosessering av CRL fra alle sertifikatmyndigheter som blir håndtert av valideringstjenesten. - En OCSP-klient kan være nødvendig for tilgang til tilbakekallingsinformasjon fra sertifikatutgivere som ikke støtter CRLs. - En database som har informasjon om sertifikatutgivere, offentlige nøkler, politikker og relaterte kvalitetsnivåer, tilbakekallingsinformasjon som oppdatert av prosessen nevnt over, og tilleggsinformasjon som kan være utledet fra sertifikatene.
Et grensesnitt (sannsynligvis LD AP) mot autoriseringstjenesten for å kunne utlede oversettelser fra navnet i sertifikatet til et gyldig brukernavn for systemets domene, og muligens andre navns formater for andre domener. Dette grensesnittet kan være fra tilgangsserveren istedenfor Valideringstjenesten, som diskutert over. - Tjenesten vil nesten helt sikkert kreve kryptografisk hardware (ikke vist i fig. 5).
Med hensyn til operasjon, forespørsler og svar, utfører OCSP-serveren, og andre frontmaskiner, protokollen avhengig av prosessering relatert til valideringstjenesten.' Dette innbefatter validering og generering av signaturer på digitalt signerte forespørsler og svaT.
Frontmaskinene har en API mot valideringsmotoren. Valideringsmotoren må analysere sertifikatet, dersom innbefattet, eller på annen måte opptre på forelagt. sertifikatinformasjon.
Valideringssjekker blir deretter utført på sertifikatet: signatur OK, sertifikatformat OK, innenfor valideringsperiode, ikke tilbakekalt eller suspendert. Noen av disse sjekkene er avhengig av et komplett sertifikat, og kan ikke bli utført dersom kun utdrag av sertifikater blir forelagt. Kvalitetsnivå blir hentet basert på politikken indikert i sertifikatet (eller fra for-konfigurert kjennskap i det spesielle tilfellet hvor utgiver ikke innbefatter anbefalt politikkidentifikatorutvidelse i sine sertifikater). Utledet informasjon blir deretter hentet fra databasen, og alle blir returnert over API til OCSP-serveren (eller annen frontmaskin) i formen spesifisert av API.
Tilbakekallingssjekking skal normalt bare være et lokalt databaseoppslag, siden CRL for-hentingskomponenten skal samle nødvendig informasjon (beskrevet under). Imidlertid dersom en sertifikatutgiver bare tilveiebringer et OCSP-grensesnitt for tilbakekallingssjekking, og ingen CRL-utgivende tjeneste, så vil valideringsmotoren faktisk kalle opp utgiverens OCSP-tjeneste.
En kan også tenke seg situasjoner hvor valideringstjenestene kan bli lenket sammen, og oppkall ble gjort ved å bruke en protokoll (ikke nødvendigvis OCSP) understøttet av frontmaskinen til fjern valideringstjenesten.
De fleste sertifikatmyndigheter i dag, bruker etter vår kjennskap signert CRL for å informere om tilbakekalling og suspensjon av sertifikater. CRL blir vanligvis utgitt regulært, med hver CRL innbefattende en planlagt tid for utgivelse av neste versjon. Imidlertid kan CRL bli utgitt før planen dersom nødvendig. Komplette CRL'er er vanlige, dvs. en CRL inneholder serietallene til alle tilbakekalte sertifikater. Et sertifikat blir fjernet fra fremtidige CRL'er når tid og utgivelse av neste CRL er etter normalutløpstid til sertifikatet. Delta-CRL'er også kalt inkrementelle CRL'er kan bli brukt hvor en CRL inneholder kun nye inntastinger siden tidligere CRL. Med delta-CRL'er, blir komplette CRL'er utgitt regulært, men mye mindre hyppig enn tilfelle er når kun komplette CRL'er blir brukt.
Dermed er normaltilfellet hvor CRL for-hentingskomponenten å kjøre en «daemon-prosess» for hver støttede sertifikatutgiver, og å hente og å prosessere utgivernes komplette CRL i en tid svært nær etter planlagt tidsutgivelse. Resultatet av prosesseringen blir lagret i databasen. Imidlertid finnes det noen varianter som må bli understøttet, og valideringstjenesten trenger å vite CRL-strategiene til forskjellige sertifikatutgivere, som dokumentert i deres fremgangsmåtepolitikker. Valideringstjenesten trenger selvfølgelig også å vite distribusjonspunkter for CRL, og den trenger å aksessere disse punktene. CRL'ene bør være åpent tilgjengelig, men noen utgivere kan ønske å fakturere for henting, i hvilket tilfelle må kostnadene enten bli overført til oppringeren, eller tatt hensyn til på annen måte.
Dersom en utgiver støtter delta-CRL'er, bør dette bli utnyttet av CRL for-hentingskomponenten siden mengden av data som er må nedlastes fra hver
. henteoperasjon vil være mye større enn de komplette CRL'ene.
Dersom en utgiver har spesifiserte lange intervaller mellom CRL'ene, er det sannsynlig at dette innebærer en «utgi CRL når nødvendig» strategi. I dette tilfellet bør CRL for-hentingskomponenten polle for ny CRL regulært i stedet for å vente på neste planlagte utgivelse. Intervallet som valideringstjenesten bør være villig til å akseptere mellom CRL'ene er en innstillingsparameter som influerer kvaliteten til valideringstjenesten. Dette intervallet bør være lik pollingstiden, og alle utgiverne med en CRL-frekvens over intervallet bør bli pollet.
For stor-skala, internasjonal operasjon, vil en sentralisert installasjon som henter potensielt svært store CRL'er fra alle utgiverne klart være inneffektivt. En installasjon i Norge som hver time trenger å hente mange. MB'er fra informasjon fra hundrevis av utgivere rundt om i verden kan virke, men den vil være inneffektiv, og utbredelse av tilbakekallingsinformasjon vil bli treg. Derfor vil en distribuert arkitektur være mer passende for CRL for-hentingskomponenten, men å beskrive denne videre er utenfor omfanget til dette dokumentet.
Det kan til slutt være noen utgivere som ikke bruker CRL<*>er i det hele tatt, men er kun avhengig av et OCSP-grensesnitt for tilbakekallingssjekking. I dette tilfellet kan ikke CRL for-hentingskomponenten gjøre noen ting, og valideringsmotoren må kalle opp passende OCSP-grensesnitt (eller annen valideringstjeneste som bemerket over) når det er nødvendig!
Strategiene brukt av CRL for-hentingskomponenten må bli innstilt i mer detalj, ettersom flere parametere enn de nevnt over vil influere resultatene. Hovedbehovet er mengde av forsinkelse som er akseptabelt å introdusere med hensyn til utbredelse av tilbakekallingsinformasjon. Det vil nødvendigvis være et «gap» eller mellomrom mellom utgivelsen av CRL og tiden når denne CRL har blitt prosessert av CRL for-hentingskomponenten. En forespørsel som ankommer ved valideringstjenesten
under dette gapet, må enten motta en forsinket respons - dersom
valideringstjenesten venter for CRL for-hentingskomponenten til å gjøre denne jobben - eller risikere et feilaktig svar dersom valideringstjenesten svarer med én gang basert på gammel tilbakekallingsinformasjon.
Det er en risiko for at en utgivers .CRL distribusjonstjeneste er overbelastet av forespørsler hver gang en planlagt CRL blir utgitt, fordi mange selskaper samtidig prøver å laste ned en ny CRL til den lokale cachen. For å håndtere dette implementerer noen utgivere en «over-issuing» strategi. CRL'ene blir utgitt oftere enn fremgangsmåtepolitikken sier. Den CRL for-hentende komponenten må ta slike forhold i betraktning.
Databasen vil lagre informasjon om hver sertifikatutgiver og dens fremgangsmåtepolitikker, og tilbakekallingsinformasjon. Det er også mulig å lagre bruketrelatert informasjon, men i den beskrevne systemkonteksten er det bedre å beholde lagring og håndtering av brukerinformasjon til autoriseringstjenesten.
Utgiverinformasjon vil bestå av utgivernavn (som spesifisert i utgivemavnfeltet i sertifikatene), identifikasjon av fremgangsmåtepolitikk som er relevant (OID
(Object Identifier) for politikken er (nesten) alltid innbefattet i sertifikatene),
offentlig nøkkel eller liste av offentlige nøkler (med valideringsintervaller og nøkkelidentifikator/nøkkelverdi) som må bli brukt for å validere sertifikatene, og kvalitetsegenskaper relatert til fremgangsmåtepolitikken og utgiveren som diskutert tidligere.
Håndtering av utgiveroffentlige nøkler er en hodepine i dag, siden dette alltid er i form av en lokal liste med pålitelige sertifikatutgivere og deres nøkler, ofte i form
av selvsignerte sertifikater (som tilveiebringer integritetsbeskyttelse men ingen autentisering). I systemet beskrevet, er utgivernøkkelhåndtering fortrinnsvis sentralisert i valideringstjenesten. Dette er kun mulig dersom komplette sertifikater blir sendt over til valideringstjenesten, og lokal sjekking av utgiverens signatur på sertifikater kan bli kortsluttet av det oppkallende systemet.
Utgivernøkler blir validert i en prosess som er delvis manuell (for å sikre kvalitet)
og delvis automatisk, og lagret i databasen. Tilbakekalling av en utgivers nøkkel er en svært sjelden hendelse, men dette er også en svært alvorlig.hendelse. Informasjonskanaler må bli overvåket for å kunne sørge for at slik tilbakekalling
blir fanget. I noen tilfeller vil tilbakekalling være gjennom CRL fra utgiver ved et høyere nivå i et hierarki. 1 andre tilfeller vil sertifikatsutgiveren som det gjelder ikke være medlem av en tillitsstruktur og må arrangere tilbakekalling på egenhånd. Imidlertid skal alltid tilbakekallingsnotifikasjon være beskrevet i fremgangsmåtepolitikken.
Noen utgivere vil kun ha et par nøkler i bruk til enhver tid, bortsett fra det vil nøkkeloverlapping fra en utgiver vanligvis medføre en overlapp hvor gammel offentlig nøkkel fremdeles er gyldig for sertifikatvalidering, mens privatnøkkelen ikke er gyldig for signering av nye sertifikater. Andre utgivere kan tilpasse en politikk for hyppige nøkkelforandringer, i hvilket tilfelle mange nøkler kan være gyldige (i det minste for sertifikatvalidering) til samme tid. Det er sannsynligvis et behov for manuelle prosedyrer for å holde databasen med en utgivers offentlige nøkler oppdatert.
Håndtering av tilbakekallingsinformasjon ble gjort av CRL for-hentingskomponenten. Tilbakekallingssjekking ble gjort lokalt ved databasesøk for å se om serienummeret til sertifikatet som er aktuelt er listet som tilbakekalt. Tilbakekallingsinformasjon må være tidsstemplet: tidspunkt for henteoperasjon for følgende informasjon, og planlagt tid for neste henting.
Hovedmotivasjonen for autoriseringstjenesten er håndtering og beskyttelse av brukerrelatert informasjon på en enkelt plass. Det er vanlig i dag å ha separate autentiserings- og autoriseringssystemer for hver tjeneste, og i det minste for hver tjenesteplattform. Dermed blir håndtering av abonnementer/brukerinformasjon - inntasting av ny informasjon, forandring og sletting av informasjon - tungvint og sårbar for feil.
Autoriseringstjenesten beholder informasjon relatert til hver bruker i én database. Tjenesten og databasen kan bli replikert. En «bruker» vil vanligvis være et individ men det kan også være en abonnentidentitet, et gruppenavn eller noen annen navngitt entitet. Informasjonen er relatert til autentisering og autoriseringer. Kontoinformasjon kan lett bli lagt til systemet, selv om dette ikke er beskrevet i dokumentet. Informasjonen vil være sensitiv med hensyn til konfidensialitet og integritet, og autoriseringstjenesten og databasen må være tilstrekkelig sikret.
I dag burde to standardprotokoller være støttet av autoriseringstjenesten: LDAP og RADIUS. DIAMETER-protokollen bør være støttet når spesifikasjonene er klare. Andre protokoller kan være støttet. Siden autoriseringstjenesten håndterer sensitiv informasjon, må den utføre autentisering og tilgangskontroll med hensyn til entiteten som kaller den i før informasjonen blir returnert. Dette kan være e' n . del av protokollene brukt, være basert på underliggende protokoller (som SSL, TLS,
IPSec, eller andre VPN-teknologier), eller stole på dedikerte
kommunikasjonskanaler (fysiske eller logiske) mot motparten. På grunn av de ulike protokollene, er det et behov for protokollspesifikke frontsystemer, på den samme måten som beskrevet for valideringstjenesten.
Autoriseringstjenesten utfører navnkartlegging for autentisering og tjenestetilgang. De PKI-baserte autentiseringsprotokollene brukt vil autentisere navnet i sertifikatet. Dette navnet kan bli sendt til autoriseringstjenesten, som i retur vil korrespondere
på brukernavnet. Navnet på tjenesten hvilket brukernavn er nødvendig, bør være en parameter til oppkallet, siden brukeren kan ha ulike brukernavn mot ulike tjenester.
Et passord kan bli returnert sammen med brukernavnet dersom nødvendig og forespurt.
Ved senere trinn av sesjonen, kan autoriseringstjenesten bli kalt opp for å få flere brukernavn når det er nødvendig. Autoriseringstjenesten kan bli gitt et brukernavn/tjenestepar, og bli spurt om å oversette dette til et annet brukertiavn/tjenestepar for tilgang til annen tjeneste. Autoriseringstjenesten må registrere styrken av autentiseringsmekanismen sist brukt av den navngitte brukeren, og opptre i henhold til dette når det innvilges eller nektes tilgang til en tjeneste ved å returnere informasjon eller ikke.
Det første nivået med autorisering i systemene er for tilgang til tjenester i seg selv. En autorisering kan være linket til spesifikke tilstander, som bruk av autentiseringsmekanismer med tilstrekkelig kvalitet, tillate lokasjoner, kun bruk av spesifikt utstyr, tiden på dagen osv. En annen betingelse er bokføring og garantert betaling, som til nå er opptil de individuelle tjenestene men kan bli lagt til i autoriseringstjenesten senere. Alle slike betingelser må være oppfylt for å få tjenesten godkjent.
I tillegg kan tjenestespesifikke autorisasjoner bli lagret i databasen. I dette tilfellet kan autoriseringstjenesten bli kalt opp fra tjenesten i seg selv under tilgangs forsøk til spesifikke objekter (som et eller annet innhold), for å bestemme om tilgangsforespørselen skal bli gitt eller ikke.
Videre utvidelser til autoriseringstjenesten er:
- Utgivelse av kryptograferte beskyttede «merker» som bevis på autoriseringer, dette kan være basert på signerte privilegier (egenskaper) sertifikater, Kerberos billetter, eller lignende teknologier.
- Håndtering av utgivelse av autoriseringer fra én bruker/aktør til en annen.
- Sammensetning av autoriseringer fra flere brukere/aktører for tilgangsavgj ørel ser.
Disse punktene er ikke beskrevet videre i dette dokumentet.
Systemet beskrevet baserer autentisering på tilgjengelig kommersielle (eller ikke kommersielle) sertifikattjenester. All sertifikathåndtering, som registrering, navngiving, utgivelse, og tilbakekalling, skal bli tatt hånd om av sertifikattilveietilbydeme.
Autoriseringstjenesten trenger å opprettholde en database av brukernavn og relaterte privilegier. Navn i sertifikatene vil ikke være direkte brukbare i denne konteksten. En kartlegging trenger derfor å bli etablert mellom brukemavnet(navnene) i sertifikatet(ene) som en bruker ønsker å bruke for å autentisere. Dette kan videre bli utvidet ved flere brukernavn mot andre tjenester, muligens også passord eller annen autentiseringsinformasjon, for å muliggjøre at tilgangsserveren logger en bruker transparent på en tjeneste som kun tillater brukernavn/passord som en autentiseringsmekanisme. I tillegg til sertifikater, kan systemet bli utvidet til å ta hånd om andre autentiseringsmekanismer, som brukernavn/passord.
Det kan være tilfeller hvor navngivningsformatet brukt av en spesifikk sertifikatutgiver kan bli automatisk oversatt til et brukernavn. Imidlertid, i de fleste tilfellene, må kartleggingen fra sertifikatnavnet til brukernavnet være eksplisitt konfigurert i databasen. For å unngå administrativ kostnad, bør dette for hoveddelen være implementert som en selvtjenestegrensesnitt for brukerne. Imidlertid vil det også være behov for et administrativt grensesnitt og definisjon av operatører med utvidede tilgangsrettigheter til databasen.
Brukere må ha tilgang til et selvtjenestegrensesnitt hvor de kan sende inn et sertifikat og detaljer rundt deres abonnement, for å kunne ha sertifikatnavn registrert og linket til brukernavnet. Linken mellom to navnformater må selvfølgelig bli etablert på lignende måte. En mulighet er at nye brukere blir gitt to alternativer: Det første er å signere opp for en konto, og samtidig bestille en elektronisk ID fra en foretrukket partner av systemeieren, eller fra en liste av alternative sertifikatutgivere. Avhengig av politikken til sertifikatutgiveren, kan den elektroniske ID'en enten være tilgjengelig for bruk med én gang, eller den trenger å bli aktivisert på et senere tidspunkt (f.eks. dersom brukeren trenger å få et smartkort). Imidlertid er, for autoriseringstjenesten den viktige informasjonen navnet som vil være synlig i sertifikatet.
Det andre er å signere opp for en konto, og spesifisere eksisterende sertifikat som vil bli brukt for å autentisere brukeren. Anvendbarheten av sertifikatet må bli sjekket mot (sikkerhets) behovene, og en må verifisere at sertifikatet faktisk tilhører den nye brukeren. Det skal være tilstrekkelig å registrere ett sertifikat og la brukeren legge til flere sertifikater senere.
Eksisterende brukere må bli tillatt å registrere tilleggssetrifikater eller erstatninger for allerede registrerte sertifikater. Dette kan være en selvadministrerende prosedyre som kan være tilgjengelig som nettbasert tjeneste. Bemerk at den trenger å ha regler for akseptable autentiseringsmetoder relatert til den nye metoden (nytt sertifikat) som vil bli registrert. F.eks., kan en ikke først introdusere et lavkvalitetssertifikat, og deretter bruke dette for å registrere et høykvalitetssertifikat som en ny autentiseringsmetode. Høykvalitetssertifikatet vil i dette tilfellet effektivt tilveiebringe samme sikkerhet som autentiseringen basert på lavkvalitetssertifikatet men en gitt konfigurering kan begrense tilgang til lavkvalitetsmetoden mens den gir tilgang for en (som det ser ut til i dette tilfellet) høykvalitetsautentisering. Følgelig kan en autentiseirngsmetode bare bli brukt for å introdusere nye metoder med samme eller lavere sikkerhetsnivå.
For å oppgradere til en sterkere autentiseirngsmetode, må prosedyrer bli fulgt for
nye brukere. Noe selvadministrering er mulig, men det kan godt hende at manuelle prosedyrer må bli innlemmet til en viss grad.
Administratorer må bli tillatt til å legge til, slette eller forandre informasjon for
andre brukere. Administratorer kan være definert internt til organisasjonen som kjører autoriseringstjenesten, relativt til (tilveiebringere av) tjenester som kan bli nådd via systemet, eller relativt til f.eks. et selskaps kunder som trenger å håndtere abonnementer for flere brukere. Administratorer kan bruke samme grensesnitt som ordinære brukere, eller et annet dersom dette passer bedre. Muligheter for batchprosessering av informasjon, f.eks. for å legge til informasjon om mange brukere i én operasjon er nødvendig.
I de fleste tilfeller er det kostnadseffektivt å overlate administrasjon av
abonnementer (dvs. autorisering til tjenester) til individuelle brukere. Dermed må selvtjenesten som er beskrevet for administrasjon av autentiseringsinformasjon også dekke annen informasjon om brukeren (faktisk vil slik bruk sannsynligvis være herskende for håndtering av autentiseringsinformasjon).
Første nivå av autoriseringer er for tjenester slik - abonnere til en tjeneste, eller bestemme et abonnement. Med et mer fingradert nivå, kan autoriseringer relatert til karakteristikker av individuelle tjenester bli håndtert, dersom slettet fra tjenesten til autoriseringstjenesten. Et eksempel kan være å forandre abonnert båndbredde for en kommunikasjonstjeneste.
Når brukere utfører slike administrative prosedyrer, må autoriseringer og andre restriksjoner bli fulgt. Som et eksempel, kan ikke en bruker abonnere til en tjeneste som trenger en sterk autentiseringsprosedyre med mindre et sertifikat med tilstrekkelig kvalitet har blitt registrert for brukeren. Et annet eksempel er relatert til innholdsabonnement i en tjeneste, som kan være begrenset til personer over en viss alder.
Administratorer er også nødvendige for å håndtere autoriseringer. Som ett
eksempel, kan fremgangsmåtepolitikken diktere at kun definerte personer kan håndtere tilgangsrettigheter til spesielle tjenester for selskapets brukere. Et batch-orientert grensesnitt er nødvendig for å håndtere informasjon om mange brukere i én enkelt operasjon.
Claims (10)
1. System for tilveiebringelse av sikker tjenestetilgang for en bruker til i det minste én tjeneste fra en tjenestetilbyder, hvor bruker og tjenestetilbyder er utstyrt med midler for forbindelse til et felles nettverk,
karakterisert ved at det omfatter: - én eller flere tilgangsservere innrettet for å utføre trinnene: å motta en forespørsel fra brukeren, å autentisere brukeren og å spørre etter klientautentisering, å utføre en anrops/responssekvens, å forespørre om et sertifikat og bevis på eierskap av privatnøkkel fra bruker, . å videresende sertifikatet eller identifikasjon av sertifikatet til en valideringstjenesteenhet, i tilfelle av gyldig brukersertifikat, å motta brukernavn fra en autoriseringstj enesteenhet, å forespørre om en autoriseringstjenesteenhet for tilgangsrettigheter, å motta tilgangsrettigheter fra autoriseringstjenesteenheten,-å lokalisere en passende tjenestemeny, å presentere tjenestemenyen til brukeren, å overføre informasjon mellom brukeren og tjenestetilbyderen;
én eller flere valideringstjenesteenheter, innrettet for å utføre trinnene: å motta et brukersertifikat eller en identifikasjon av et brukersertifikat fra tilgangsserveren, å kontrollere gyldigheten til brukersetrifikatet, dersom brukersetrifikatet er gyldig, enten å oversende brukersertifikatsnavnet til en autoriseringstjenesteenhet for oversetting til et brukernavn, og å oversende brukernavnet returnert fra autoriseringstjenesteenheten til tilgangsserveren, eller å oversende brukerens sertifikatnavn til tilgangsserveren, dersom brukerens sertifikat ikke er gyldig, å nekte brukeren tilgang til tjenesten; - én eller flere autoriseringstjenesteenheter, innrettet for å utføre trinnene: å motta en brukers sertifikatnavn fra en valideringstjenesteenhet eller en tilgangsserver, å' sende brukerens sertifikatnavn til en database, å motta brukerens navn og profil fra databasen, å oversende brukernavnet til en valideringstjenesteenhet eller tilgangsserveren, å motta en forespørsel om tilgangsrettigheter fra en tilgangsserver, å forespørre om abonnementsinfo fra databasen,
r å motta abonnementsinfo fra databasen, å bestemme tilgangsrettigheter basert på nevnte abonnementsinfo, å oversende tilgangsrettigheter til tilgangsserveren; og - én eller flere autorisasjonsrolleenheter og tilhørende databaser, innrettet for å utføre trinnene: å motta en brukers sertifikat fra en autoriseringstjenesteenhet, å lokalisere brukerens navn og profil i databasen, å sende brukerens navn og profil til autoriseringstjenesteenheten, å motta en forespørsel om abonnementsinfo fra en autoriseringstjenesteenhet, å sende abonnementsinfo til autoriseringstjenesteenheten;
hvilket medfører at systemet tillater brukeren å benytte ett og samme sertifikat, utstedt av en ekstern sertifikattilbyder, for sikker tilgang til tjenestene.
2. System i henhold til krav 1,
karakterisert ved. at tilgangsserveren omfatter midler for: å støtte HTTPS eller andre midler for sikre kommunikasjonskanaler, autentisering av tilgangsserveren til klienter/brukere, fortrinnsvis ved bruk av PKI-teknologi, å støtte protokoller som er nødvendig for å kommunisere med valideringstjenesten og autoriseringstjenesteenheten, å støtte én eller flere protokoller for PKI-basert klient/brukerautentisering, å implementere funksjonaliteten som er nødvendig for fremvisning av informasjon til brukeren og for å håndtere brukerinnmating, å opptre som proksyserver mellom bruker og tjeneste.
3. System i henhold til krav 1,
karakterisert ved at forespørring av sertifikat og privatnøkkel fra
brukeren kan bli utført ved å bruke registeroppslag.
4. System i henhold til krav 1,
karakterisert ved at tilgangsserveren blir tilpasset for å formidle direkte tilgang til tjenesten på en enkel påloggingsmåte.
5. System i henhold til krav 1,
karakterisert ved at databasen som lagrer brukernavn og profil også lagrer annen brukerrelatert informasjon.
6. System i henhold til krav 2,
karakterisert ved at når det brukes andre midler for sikring av kommunikasjonskanal, etablerer tilgangsserveren en sikker sesjon slik som en SSL/TLS-sesjon kun med serverautentisering, og som kjører brukerautentiseringsprotokoll på den etablerte sikre kanalen.
7. System i henhold til krav 2,
karakterisert ved at i tilfelle av flere alternativer med autentiseringsmetoder, blir brukeren presentert med valgene, og tilgangsserveren etablerer en sikker sesjon slik som en SSL/TLS-sesjon med den valgte metoden til kli en taut enti seringen.
8. System i henhold til krav 4,
karakterisert ved at tjenestetilbyderen er innbefattet i systemet og tilpasset for å ha tilgang til utvekslingsinformasjon med autoriseringsenheten.
9. Anvendelse av systemet i henhold til krav l for å tilveiebringe autentisering, autorisering og tilgang til verdiøkte tjenester slik som Video on Demand.
10. Fremgangsmåte for å tilveiebringe sikker tjenestetilgang for en bruker til i det minste én tjeneste fra en tjenestetilbyder, hvor kunden og tjenestetilbyderen er
utstyrt med midler for forbindelse til et felles nettverk,
karakterisert ved at det omfatter trinnene: - ved hjelp av én eller flere tilgangsservere: å motta en forespørsel fra brukeren, å autentisere brukeren og å spørre etter klientautentisering, å utføre en anrops/responssekvens, å forespørre om et sertifikat og bevis på eierskap til privatnøkkel fra brukeren, å overføre sertifikatet eller identifikasjon av sertifikatet til en valideringstjenesteenhet, i tilfelle av gyldig brukersertifikat, å motta et brukernavn fra en autoriseringstjenesteenhet, å forespørre en autoriseringstjenesteenhet om tilgangsrettigheter, å motta tilgangsrettigheter fra autoriseringstjenesteenheten, å lokalisere en passende tjenestemeny, å presentere tjenestemenyen til brukeren, å overføre informasjon mellom brukeren og tjenestetilbyderen; - ved hjelp av én eller flere valideringstjenesteenheter: å motta et brukersertifikat eller en identifikasjon av brukersertifikat fra en tilgangsserver,
å kontrollere gyldigheten til brukersertifikatet, dersom brukersertifikatet er gyldig, enten å sende brukernes sertifikatnavn til en autoriseringstjenesteenhet for oversetting til et brukernavn, og overføring av brukernavnet returnert fra autoriseringstjenesteenheten til tilgangsserveren, eller å overføre brukerens sertifikatnavn til tilgangsserveren, dersom brukerens sertifikat ikke er gyldig, å nekte brukeren tilgang til tjenesten; - ved hjelp av én eller flere autoriseringstjenesteenheter: å motta en brukers sertifikatnavn fra en valideringsserviceenhet eller en tilgangsserver, å sende brukerens sertifikatnavn til en database, å motta brukernavn og profil fra en database, å overføre brukernavnet til en valideringstjenesteenhet eller tilgangsserver, å motta en forespørsel om tilgangsrettigheter fra en tilgangsserver, å forespørre om abonnementsinfo fra databasen, å motta abonnementsinfo fra databasen,
å bestemme tilgangsrettigheter basert på abonnementsinfo, å overføre tilgangsrettigheter til tilgangsserveren, - ved hjelp av én eller flere autoriseringsrolleenheter og tilhørende databaser: å motta en brukers sertifikat fra en autoriseringstjenesteenhet, å lokalisere et brukernavn og profil i databasen, å sende brukernavnet og profilen til autoriseringstjenesteenheten, å motta en forespørsel om abonnementsinfo fra en autoriseringstjenesteenhet, å sende abonnementsinfo til autoriseringstjenesteenheten;
hvilket medfører at fremgangsmåten tillater brukeren å benytte ett og samme sertifikat, utstedt av en ekstern sertifikattilbyder, for sikker tilgang til tjenestene.
Priority Applications (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
NO20021341A NO318842B1 (no) | 2002-03-18 | 2002-03-18 | Autentisering og tilgangskontroll |
PCT/NO2003/000093 WO2003079167A1 (en) | 2002-03-18 | 2003-03-18 | Single sign-on secure service access |
CNA038108100A CN1745356A (zh) | 2002-03-18 | 2003-03-18 | 单一签名安全服务访问 |
CA002479183A CA2479183A1 (en) | 2002-03-18 | 2003-03-18 | Single sign-on secure service access |
JP2003577102A JP2005521279A (ja) | 2002-03-18 | 2003-03-18 | セキュア・サービス・アクセス提供システム及び方法 |
US10/507,131 US20050144463A1 (en) | 2002-03-18 | 2003-03-18 | Single sign-on secure service access |
EP03708750A EP1485771A1 (en) | 2002-03-18 | 2003-03-18 | Single sign-on secure service access |
RU2004130424/09A RU2308755C2 (ru) | 2002-03-18 | 2003-03-18 | Система и способ предоставления доступа к защищенным услугам с однократным вводом пароля |
AU2003212723A AU2003212723B2 (en) | 2002-03-18 | 2003-03-18 | Single sign-on secure service access |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
NO20021341A NO318842B1 (no) | 2002-03-18 | 2002-03-18 | Autentisering og tilgangskontroll |
Publications (3)
Publication Number | Publication Date |
---|---|
NO20021341D0 NO20021341D0 (no) | 2002-03-18 |
NO20021341L NO20021341L (no) | 2003-09-19 |
NO318842B1 true NO318842B1 (no) | 2005-05-09 |
Family
ID=19913444
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
NO20021341A NO318842B1 (no) | 2002-03-18 | 2002-03-18 | Autentisering og tilgangskontroll |
Country Status (9)
Country | Link |
---|---|
US (1) | US20050144463A1 (no) |
EP (1) | EP1485771A1 (no) |
JP (1) | JP2005521279A (no) |
CN (1) | CN1745356A (no) |
AU (1) | AU2003212723B2 (no) |
CA (1) | CA2479183A1 (no) |
NO (1) | NO318842B1 (no) |
RU (1) | RU2308755C2 (no) |
WO (1) | WO2003079167A1 (no) |
Families Citing this family (83)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6965999B2 (en) * | 1998-05-01 | 2005-11-15 | Microsoft Corporation | Intelligent trust management method and system |
US7444368B1 (en) * | 2000-02-29 | 2008-10-28 | Microsoft Corporation | Methods and systems for selecting methodology for authenticating computer systems on a per computer system or per user basis |
US7568218B2 (en) * | 2002-10-31 | 2009-07-28 | Microsoft Corporation | Selective cross-realm authentication |
KR100561629B1 (ko) * | 2003-12-03 | 2006-03-20 | 한국전자통신연구원 | 보안 정보 통합 관리 시스템 및 그 방법 |
US8473620B2 (en) * | 2003-04-14 | 2013-06-25 | Riverbed Technology, Inc. | Interception of a cloud-based communication connection |
US7496755B2 (en) * | 2003-07-01 | 2009-02-24 | International Business Machines Corporation | Method and system for a single-sign-on operation providing grid access and network access |
US7536543B1 (en) * | 2003-10-09 | 2009-05-19 | Nortel Networks Limited | System and method for authentication and authorization using a centralized authority |
US7574603B2 (en) * | 2003-11-14 | 2009-08-11 | Microsoft Corporation | Method of negotiating security parameters and authenticating users interconnected to a network |
CA2551819C (en) * | 2004-01-09 | 2015-02-24 | Corestreet, Ltd. | Signature-efficient real time credentials for ocsp and distributed ocsp |
US7506369B2 (en) * | 2004-05-27 | 2009-03-17 | Microsoft Corporation | Secure federation of data communications networks |
US7617501B2 (en) | 2004-07-09 | 2009-11-10 | Quest Software, Inc. | Apparatus, system, and method for managing policies on a computer having a foreign operating system |
KR100813791B1 (ko) * | 2004-09-30 | 2008-03-13 | 주식회사 케이티 | 유무선 통합서비스 망에서의 개인 이동성을 위한 통합인증 처리 장치 및 그 방법 |
US7995758B1 (en) * | 2004-11-30 | 2011-08-09 | Adobe Systems Incorporated | Family of encryption keys |
US7676587B2 (en) * | 2004-12-14 | 2010-03-09 | Emc Corporation | Distributed IP trunking and server clustering for sharing of an IP server address among IP servers |
US20060225128A1 (en) * | 2005-04-04 | 2006-10-05 | Nokia Corporation | Measures for enhancing security in communication systems |
US20060294383A1 (en) * | 2005-06-28 | 2006-12-28 | Paula Austel | Secure data communications in web services |
KR100648986B1 (ko) | 2005-08-05 | 2006-11-27 | 주식회사 비티웍스 | 전자명함 서비스 시스템 및 방법과 전자명함 인증 장치 및방법과 이를 위한 컴퓨터로 읽을 수 있는 기록 매체 |
US20090083537A1 (en) * | 2005-08-10 | 2009-03-26 | Riverbed Technology, Inc. | Server configuration selection for ssl interception |
US8438628B2 (en) * | 2005-08-10 | 2013-05-07 | Riverbed Technology, Inc. | Method and apparatus for split-terminating a secure network connection, with client authentication |
US8613071B2 (en) * | 2005-08-10 | 2013-12-17 | Riverbed Technology, Inc. | Split termination for secure communication protocols |
US8478986B2 (en) * | 2005-08-10 | 2013-07-02 | Riverbed Technology, Inc. | Reducing latency of split-terminated secure communication protocol sessions |
US8775586B2 (en) * | 2005-09-29 | 2014-07-08 | Avaya Inc. | Granting privileges and sharing resources in a telecommunications system |
US8701168B2 (en) * | 2005-11-21 | 2014-04-15 | Oracle International Corporation | Method and apparatus for associating a digital certificate with an enterprise profile |
US7904949B2 (en) | 2005-12-19 | 2011-03-08 | Quest Software, Inc. | Apparatus, systems and methods to provide authentication services to a legacy application |
US8087075B2 (en) * | 2006-02-13 | 2011-12-27 | Quest Software, Inc. | Disconnected credential validation using pre-fetched service tickets |
US8782393B1 (en) | 2006-03-23 | 2014-07-15 | F5 Networks, Inc. | Accessing SSL connection data by a third-party |
DE102006018889A1 (de) * | 2006-04-18 | 2007-10-25 | Siemens Ag | Verfahren zum Beschränken des Zugriffs auf Daten von Gruppenmitgliedern und Gruppenverwaltungsrechner |
FI20065288A (fi) | 2006-05-03 | 2007-11-04 | Emillion Oy | Autentikointi |
US8429712B2 (en) | 2006-06-08 | 2013-04-23 | Quest Software, Inc. | Centralized user authentication system apparatus and method |
US8086710B2 (en) | 2006-10-30 | 2011-12-27 | Quest Software, Inc. | Identity migration apparatus and method |
US7895332B2 (en) | 2006-10-30 | 2011-02-22 | Quest Software, Inc. | Identity migration system apparatus and method |
US20080114987A1 (en) * | 2006-10-31 | 2008-05-15 | Novell, Inc. | Multiple security access mechanisms for a single identifier |
US8572716B2 (en) | 2007-04-23 | 2013-10-29 | Microsoft Corporation | Integrating operating systems with content offered by web based entities |
US8738897B2 (en) * | 2007-04-25 | 2014-05-27 | Apple Inc. | Single sign-on functionality for secure communications over insecure networks |
US9159179B2 (en) * | 2007-05-31 | 2015-10-13 | Ricoh Company, Ltd. | Common access card security and document security enhancement |
KR101393012B1 (ko) * | 2007-07-03 | 2014-05-12 | 삼성전자주식회사 | 라이센스 관리 시스템 및 방법 |
JP5016678B2 (ja) * | 2007-10-19 | 2012-09-05 | 日本電信電話株式会社 | 利用者認証システム及びその方法 |
EP2053531B1 (en) * | 2007-10-25 | 2014-07-30 | BlackBerry Limited | Authentication certificate management for access to a wireless communication device |
US8397077B2 (en) * | 2007-12-07 | 2013-03-12 | Pistolstar, Inc. | Client side authentication redirection |
US8156550B2 (en) * | 2008-06-20 | 2012-04-10 | Microsoft Corporation | Establishing secure data transmission using unsecured E-mail |
US8631134B2 (en) * | 2008-07-30 | 2014-01-14 | Visa U.S.A. Inc. | Network architecture for secure data communications |
KR101094577B1 (ko) | 2009-02-27 | 2011-12-19 | 주식회사 케이티 | 인터페이스 서버의 사용자 단말 인증 방법과 그 인터페이스 서버 및 사용자 단말 |
US8707043B2 (en) * | 2009-03-03 | 2014-04-22 | Riverbed Technology, Inc. | Split termination of secure communication sessions with mutual certificate-based authentication |
US20100241852A1 (en) * | 2009-03-20 | 2010-09-23 | Rotem Sela | Methods for Producing Products with Certificates and Keys |
WO2010144898A1 (en) * | 2009-06-12 | 2010-12-16 | General Instrument Corporation | Certificate status information protocol (csip) proxy and responder |
CN101572888B (zh) * | 2009-06-18 | 2012-03-28 | 浙江大学 | 移动终端中多服务引擎交叉验证方法 |
US9608826B2 (en) * | 2009-06-29 | 2017-03-28 | Jpmorgan Chase Bank, N.A. | System and method for partner key management |
US8255984B1 (en) | 2009-07-01 | 2012-08-28 | Quest Software, Inc. | Single sign-on system for shared resource environments |
US8683196B2 (en) * | 2009-11-24 | 2014-03-25 | Red Hat, Inc. | Token renewal |
WO2011078723A1 (ru) * | 2009-12-25 | 2011-06-30 | Starodubtsev Valeriy Ivanovich | Система заказов и продажи товаров и услуг (варианты), способ предложения к продаже и оформления заказов, способ продажи товаров и услуг |
CN102754115B (zh) * | 2010-01-19 | 2018-09-18 | 维萨国际服务协会 | 远程可变认证处理 |
US9118485B2 (en) * | 2010-02-26 | 2015-08-25 | Red Hat, Inc. | Using an OCSP responder as a CRL distribution point |
US8700892B2 (en) | 2010-03-19 | 2014-04-15 | F5 Networks, Inc. | Proxy SSL authentication in split SSL for client-side proxy agent resources with content insertion |
US8566468B2 (en) * | 2010-05-12 | 2013-10-22 | Alcatel Lucent | Extensible data driven message validation |
US8836470B2 (en) | 2010-12-02 | 2014-09-16 | Viscount Security Systems Inc. | System and method for interfacing facility access with control |
US8854177B2 (en) * | 2010-12-02 | 2014-10-07 | Viscount Security Systems Inc. | System, method and database for managing permissions to use physical devices and logical assets |
KR20120069361A (ko) * | 2010-12-20 | 2012-06-28 | 한국전자통신연구원 | 네트워크 공격 관리 방법 및 시스템, 네트워크 공격 관리를 위한 네트워크 서비스 제공 장치 |
WO2013049689A1 (en) * | 2011-09-29 | 2013-04-04 | Amazon Technologies, Inc. | Parameter based key derivation |
US9203613B2 (en) | 2011-09-29 | 2015-12-01 | Amazon Technologies, Inc. | Techniques for client constructed sessions |
US8844013B2 (en) * | 2011-10-04 | 2014-09-23 | Salesforce.Com, Inc. | Providing third party authentication in an on-demand service environment |
JP5812797B2 (ja) * | 2011-10-14 | 2015-11-17 | キヤノン株式会社 | 情報処理システム、画像処理装置、制御方法、コンピュータプログラムおよびユーザ装置 |
US8752203B2 (en) * | 2012-06-18 | 2014-06-10 | Lars Reinertsen | System for managing computer data security through portable data access security tokens |
JP6019839B2 (ja) * | 2012-07-09 | 2016-11-02 | 沖電気工業株式会社 | 入力装置及び紙葉類取扱装置 |
CN103716292A (zh) * | 2012-09-29 | 2014-04-09 | 西门子公司 | 一种跨域的单点登录的方法和设备 |
US9270667B2 (en) * | 2012-11-01 | 2016-02-23 | Microsoft Technology Licensing, Llc | Utilizing X.509 authentication for single sign-on between disparate servers |
US9565211B2 (en) | 2013-03-15 | 2017-02-07 | True Ultimate Standards Everywhere, Inc. | Managing exchanges of sensitive data |
US9864873B2 (en) | 2013-03-15 | 2018-01-09 | Trustarc Inc | Managing data handling policies |
JP5920260B2 (ja) * | 2013-03-19 | 2016-05-18 | 富士ゼロックス株式会社 | 通信システム、中継装置及びプログラム |
US9419963B2 (en) * | 2013-07-02 | 2016-08-16 | Open Text S.A. | System and method for controlling access |
US10326597B1 (en) | 2014-06-27 | 2019-06-18 | Amazon Technologies, Inc. | Dynamic response signing capability in a distributed system |
RU2610258C2 (ru) * | 2014-11-28 | 2017-02-08 | Общество С Ограниченной Ответственностью "Яндекс" | Способ (варианты) и система (варианты) анонимной авторизации на сервисе пользователя |
US9613204B2 (en) | 2014-12-23 | 2017-04-04 | Document Storage Systems, Inc. | Computer readable storage media for legacy integration and methods and systems for utilizing same |
US9705859B2 (en) * | 2015-12-11 | 2017-07-11 | Amazon Technologies, Inc. | Key exchange through partially trusted third party |
JP6508067B2 (ja) * | 2016-01-14 | 2019-05-08 | 株式会社デンソー | 車両用データ通信システム |
US10116440B1 (en) | 2016-08-09 | 2018-10-30 | Amazon Technologies, Inc. | Cryptographic key management for imported cryptographic keys |
EP3297242B1 (en) * | 2016-09-20 | 2018-09-05 | Deutsche Telekom AG | A system and a method for providing a user with an access to different services of service providers |
RU2693330C2 (ru) * | 2017-12-27 | 2019-07-02 | Общество С Ограниченной Ответственностью "Яндекс" | Способ и система для авторизации пользователя для выполнения действия в электронном сервисе |
CN110362412A (zh) | 2018-04-09 | 2019-10-22 | 华为技术有限公司 | 一种服务api调用方法和相关装置 |
RU2709288C1 (ru) * | 2019-03-04 | 2019-12-17 | федеральное государственное казенное военное образовательное учреждение высшего образования "Краснодарское высшее военное училище имени генерала армии С.М. Штеменко" Министерства обороны Российской Федерации | Способ защищенного доступа к базе данных |
CN112214211B (zh) * | 2020-09-25 | 2023-08-01 | 华迪计算机集团有限公司 | 基于soa架构的应用***集成平台 |
EP4002756B1 (en) * | 2020-11-24 | 2022-11-02 | Axis AB | Systems and methods of managing a certificate associated with a component located at a remote location |
CN114398612B (zh) * | 2021-12-08 | 2024-05-03 | 国网辽宁省电力有限公司 | 一种基于微服务的ict虚拟运营安全接入管控方法 |
CN115225350B (zh) * | 2022-07-01 | 2024-05-31 | 浪潮云信息技术股份公司 | 基于国密证书的政务云加密登录验证方法及存储介质 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7137006B1 (en) * | 1999-09-24 | 2006-11-14 | Citicorp Development Center, Inc. | Method and system for single sign-on user access to multiple web servers |
US5944824A (en) * | 1997-04-30 | 1999-08-31 | Mci Communications Corporation | System and method for single sign-on to a plurality of network elements |
US6182142B1 (en) * | 1998-07-10 | 2001-01-30 | Encommerce, Inc. | Distributed access management of information resources |
CA2400623C (en) * | 2000-03-17 | 2007-03-20 | At&T Corp. | Web-based single-sign-on authentication mechanism |
US6853728B1 (en) * | 2000-07-21 | 2005-02-08 | The Directv Group, Inc. | Video on demand pay per view services with unmodified conditional access functionality |
AU2002212345A1 (en) * | 2000-11-09 | 2002-05-21 | International Business Machines Corporation | Method and system for web-based cross-domain single-sign-on authentication |
US7185364B2 (en) * | 2001-03-21 | 2007-02-27 | Oracle International Corporation | Access system interface |
-
2002
- 2002-03-18 NO NO20021341A patent/NO318842B1/no not_active IP Right Cessation
-
2003
- 2003-03-18 CN CNA038108100A patent/CN1745356A/zh active Pending
- 2003-03-18 RU RU2004130424/09A patent/RU2308755C2/ru not_active IP Right Cessation
- 2003-03-18 EP EP03708750A patent/EP1485771A1/en not_active Withdrawn
- 2003-03-18 WO PCT/NO2003/000093 patent/WO2003079167A1/en active IP Right Grant
- 2003-03-18 AU AU2003212723A patent/AU2003212723B2/en not_active Ceased
- 2003-03-18 US US10/507,131 patent/US20050144463A1/en not_active Abandoned
- 2003-03-18 CA CA002479183A patent/CA2479183A1/en not_active Abandoned
- 2003-03-18 JP JP2003577102A patent/JP2005521279A/ja active Pending
Also Published As
Publication number | Publication date |
---|---|
RU2308755C2 (ru) | 2007-10-20 |
JP2005521279A (ja) | 2005-07-14 |
EP1485771A1 (en) | 2004-12-15 |
AU2003212723B2 (en) | 2007-05-24 |
RU2004130424A (ru) | 2005-07-10 |
AU2003212723A1 (en) | 2003-09-29 |
CN1745356A (zh) | 2006-03-08 |
US20050144463A1 (en) | 2005-06-30 |
WO2003079167A1 (en) | 2003-09-25 |
NO20021341L (no) | 2003-09-19 |
CA2479183A1 (en) | 2003-09-25 |
NO20021341D0 (no) | 2002-03-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
NO318842B1 (no) | Autentisering og tilgangskontroll | |
JP5844001B2 (ja) | マルチパーティシステムにおける安全な認証 | |
US7146009B2 (en) | Secure electronic messaging system requiring key retrieval for deriving decryption keys | |
US6668322B1 (en) | Access management system and method employing secure credentials | |
US6691232B1 (en) | Security architecture with environment sensitive credential sufficiency evaluation | |
US7793095B2 (en) | Distributed hierarchical identity management | |
US9002018B2 (en) | Encryption key exchange system and method | |
US9122865B2 (en) | System and method to establish and use credentials for a common lightweight identity through digital certificates | |
US7320073B2 (en) | Secure method for roaming keys and certificates | |
EP1841174A1 (en) | Methods and systems for multifactor authentication | |
US9667618B2 (en) | Method for domain control validation | |
US9521138B2 (en) | System for domain control validation | |
US20080263644A1 (en) | Federated authorization for distributed computing | |
WO2005125077A1 (en) | Graduated authentication in an identity management system | |
WO2007125180A1 (en) | Authentication | |
JP5602165B2 (ja) | ネットワーク通信を保護する方法および装置 | |
CN107872455A (zh) | 一种跨域单点登录***及其方法 | |
US20230299973A1 (en) | Service registration method and device | |
AU2003240323A1 (en) | Distributed hierarchical identity management | |
CA2458257A1 (en) | Distributed hierarchical identity management | |
IES20070726A2 (en) | Automated authenticated certificate renewal system | |
IES85034Y1 (en) | Automated authenticated certificate renewal system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
MM1K | Lapsed by not paying the annual fees |