SE527706C2 - System, förfarande och anordning för federerade single sign- on tjänster - Google Patents

Description

527 706 2 Det s k "nätcentriska" tillvägagångssättet är lämpligt när förtroliga relationer inom domänen finns mellan autentiseringsleverantörer och tjänsteleverantören medan det terrninalcentriska tillvägagångssättet är användbart när sådana relationer saknas och terminalen kan söka autentiseringen mot olika domäner eller tjänster.

Det är också möjligt att kombinera de båda tillvägagångssätten. En nätoperatör kan utfärda kredítiv såsom digitala certifikat, korttidscertifikat, eller temporära biljetter eller bevis som kan lagras i terminalen eller i ett tillgängligt läs-/skrivkort. Dessa används vidare av användaren vid autentiserings- eller auktoriseringsprocedurer.

Konventionella mobila operatörer använder autentiseringstjänster för att bevilja användare tillgång till röst- och datatj änster som tillhandahålls av sådana operatörer. När mobila operatörer förflyttar sig uppåt i värdekedjan, skulle de kunna höja sina ömsesidiga förtroliga relationer med sina egna abonnenter för att spela en ny roll av autentiseringsleverantörer för sina resp. abonnentpopulationer i växlande affarsmodeller, i vilka tjänstedomäner och autentiseringstjänster tillhör olika administrativa enheter. I detta avseende, skulle en operatör som kan tillhandahålla både accesser, nämligen IP- förbindelse och tjänster, ytterligare kunna erbjuda sina abonnenter "en åtkomst- autentiserings SSO" så att en autentisering som utförs på åtkomstnivå skulle kunna vara giltig som autentisering i en tjänstedomän. Detta är en relevant utgångspunkt för vidare beskrivning av syftena med den föreliggande uppfinningen.

Mer i detalj, måste relationen mellan en tjänstedomän och en autentiseringsleverantör, liksom tjänsterna som en användare kan erbjudas, tas i beaktning för att diskutera fördelar och nackdelar hos de ovan nämnda tillvägagångssätten. I allmänna ordalag, kan en autentiseringsleverantör tillhöra samma administrativa domän som tjänsteleverantören som erbjuder tjänsten, eller skulle kunna delegeras till en extem förtrolig part eller till en distribuerad sammanslutning.

Ett primärt syfte med den föreliggande uppfinningen är stödet för single sign-on (SSO) tjänster för abonnenter i en sammanslutning av mobila nätoperatörer (MNO), abonnenter 10 15 20 25 30 527 706 3 som är användare av olika tjänsteleverantörer (service providers (SP)). SSO-tjänster får stöd på så sätt att användare, sammanslutningar av mobila nätoperatörer, och tjänsteleverantörer har överenskommelser med åtminstone en medlem av en sådan sammanslutning, och alla får ytterligare fördelar och värdehöj ande tjänster från en given arkitektonisk och affärsmässig referensmodell i enlighet med denna uppfinning.

Mer i detalj, får användaren fördelen hos SSG-tjänsten att få tillgång till vilken som helst tjänst vid vilken som helst tjänsteleverantör (SP) inom överenskommelsen i referensmodellen. De mobila nätoperatörerna (MNO) kan få vinster genom att erbjuda SSO-tjänster, i synnerhet autentisering och auktorisering, till tredje parter liksom upprätthålla abonnentlojalitet genom att ge mervärde till sina resp. mobila abonnenter. I ett senare läge kan tjänsteleverantörema uppleva en ökning av potentiella användare, nämligen mobila abonnenter, med en enklare och mycket säkrare autentiserings- och auktoriseringsmekanism som minimerar supporten för olika sådana mekanismer beroende på de olika slagen användare. I detta scenario tillhör autentiseringsleverantören och tjänsteleverantören olika administrativa domäner. Samtidigt, ger dessa distribuerade fördelar möjlighet till en ökning av s k e-handel (mobile commerce (m-commerce)), vilket kan ses som ett ytterligare ändamål hos föreliggande uppfinning.

BESLÄKTAD TEKNIK Det "nätcentriska" tillvägagångssättet, som beskrivs ovan, verkar vara mer lämpligt för scenarion som involverar användare av tjänsteleverantörer som också är abonnenter till mobila nätoperatörer, de senare som vill spela rollen av autentiseringsleverantörcr.

Emellertid diskuteras den närmast kända tekniken här med hänvisning till SSO-tjänster i ett generiskt nätcentriskt tillvägagångssätt beroende av typ av nät som verkar som autentiseringsleverantör.

T ex beskriver den publicerade US patentansökningen US 2002/0010776 A1 av Lerner förfaranden och system för tillhandahållande av en single sign-on (SSO) distribuerad applikationstj änst som är integrerad för autentiserings- och auktoriseringstjänster. De 10 15 20 25 30 527 706 4 relevanta beskrivningarna i denna ansökan börjar med en första indikation från en användare, som pekar på en browser i en första applikation, vlken indikation mottas vid en central server som är kopplad till användarterrninalen. Sedan mottas också en s k cookiefil, som motsvarar användaren också vid den centrala servern, från browsern tillhörande den första applikationen. Den centrala servem uppdaterar sedan cookiefilen som mottas från browsem.

En cookiefil är ett datasegment av variabel längd och inkluderar vanligtvis hundratals bytes. Dessa cookies skrivs, läses och modifieras av ett applikationsgränssnitt med bibliotek som finns i varje ansluten webserver, vare sig denna är lokal till den centrala servem eller finns i en avlägsen partners site. Mer specifikt, inkluderar uppdateringen av en mottagen cookieñl jämförelsen av cookiefilen med vissa på förhand bestämda parametrar och den eventuella modifieringen av cookiefilen baseras på denna jämförelse.

När en andra indikation från användaren mottas vid den centrala servem som indikerar att användaren ger en pekare för servem till en andra applikation, tillhandahåller den centrala servem denna uppdaterade cookiefil till den andra applikationen.

Denna patentansökan beskriver att det ovan nänmda biblioteket med applikationsgränssnitt, vilket är ansvarigt för att skriva, läsa och modifiera cookiefiler, är konfigurerat för att också autentisera användare mellan olika applikationer. Till följd av detta, skulle en fackrnan inom området snabbt inse att autentiseringsdata och motsvarande funktioner för alla användare finns i varje ansluten webserver, vid lokala eller avlägsna partners platser, vilket är en ytterligare nackdel för administrering. Mer specifikt, vidtas olika åtgärder vid varje applikation i en ansluten webserver, vilken browser pekas på av användaren, med hänsyn till autentiseringen av en sådan användare även om användaren har fått fördelen av en SSO-tjänst. Således kan man se denna mekanism som ett exempel på ett scenario där autentiseringsleverantören och tjänsteleverantören tillhör samma administrativa domän. 10 15 20 25 30 527 706 5 Den ovanstående beskrivningen förefaller inte vara tillämplig för stora telekommunikationssystem som innefattar en sammanslutning av mobila nätoperatörer, ett flertal olika tj änsteleverantörer som har likartat undertecknade överenskommelser med åtminstone en medlem i sammanslutningen, och ett stort antal möjliga användare som är mobila abonnenter hos någon av medlemmarna i sammanslutningen.

Vidare, givet att abonnentautentiseringsdata och algoritmer är riktigt känslig information, är de mobila nätoperatörema mycket tveksamma till att sprida denna information till enheter utanför deras egna affärslokaler.

Ett annat signifikant exempel på förfaranden och system för single sign-on användartillgänglighet beskrivs i den europeiska patentansökningen EP-1089516 med Grandcolas et al. som uppfinnare där användare kan få tillgång till ett flertal webservrar.

Denna ansökan beskriver hur en användare autentiseras vid en första webserver som tillåter användaren att välja en andra webserver som erbjuder en önskvärd tjänst. När användaren effektivt väljer den andra webservem, konstruerar den första webservem ett krypterat autentiseringsbevis, och skickar detta till den andra webservem. Den andra webservem autentiserar det mottagna beviset och tillåter användaren en session vid denna andra webserver. Båda av de första och andra webservrarna delar, i enlighet med denna ansökning, en subdomän. Det betyder att scenariot i denna ansökning är ett exempel där autentiseringsleverantören, nämligen den första webservern, och tjänsteleverantören, nämligen den andra webservem, båda tillhör samma administrativa domän.

Därför kan beskrivningen i denna ansökning inte användas vid scenarior där autentiseringsleverantören och tjänsteleverantören tillhör olika administrativa domäner.

Det betyder att den första webservem i denna applikation, autentiseringsleverantören, är den första kontakten för användaren som vill ha åtkomst till den andra webservem där tjänsten erbjuds. 10 15 20 25 30 527 706 6 Till följd av detta kan detta tillvägagångssätt inte vara lämpligt för kommersiell användning vid scenarior där autentiseringsleverantören och tjänsteleverantören tillhör olika administrativa domäner. I sådana scenarior får användaren direkt åtkomst till en tjänsteleverantör som begär en autentiseringsmyndighet att autentisera användaren och, så snart en sådan autentisering har utförts med framgång auktoriserar autentiseringsmyndigheten tjänsteleverantören att erbjuda den valda tjänsten för den användaren.

En känd lösning i dag, som är representativ för ett scenario där autentiseringsleverantören och tjänsteleverantören tillhör olika administrativa och kommersiella domäner är Microsoft® .NET pass-produkten (som beskrivs i http:/www.passport.com och i det följande enbart kommer att hänvisas till som ".NET-passet"). Denna produkt är avsedd att bygga upp ett bredare internetbaserat förtroligt nät med en gemensam uppsättning tekniska och operationella riktlinjer som är öppet för vilken som helst organisation som stöder motsvarande standarder.

Emellertid löser detta tillvägagångssätt inte problemet att bygga upp en sammanslutning av mobila nätoperatörer som skall ha ansvar för autentisering av sina egna mobilabonnenter som vill ha åtkomst till tj änsteleverantörer som är förbundna med åtminstone en medlem av en sådan sammanslutning. Vidare gäller det för ett tillvägagångssätt som .NET-passet, vilket är avsett att bli ett mycket stort internetautentiseringssystem, att en nära lösning baserad på en centraliserad autentiseringsmyndighet som inte erbjuder några fördelar måste hantera de mobila nätoperatörema och abonnenter.

Därför är det ett viktigt syfte med den föreliggande uppfinningen att tillhandahålla ett system, organ och förfarande för att bygga upp en sammanslutning av mobila nätoperatörer (MNO) som verkar som en autentiseringsmyndighet mot anslutna tjänsteleverantörer (SP) som erbjuder single sign-on (SSO) tjänster till abonnenter till vilken som helst MNO i sarnrnanslutningen. Det är annat syfte med den föreliggande uppfinningen att sammanslutningen som verkar som en autentiseringsmyndighet således 10 15 20 25 30 527 706 7 utför säkerhets- och privacy-relaterade krav på samma eller högre nivå än de som f n används av mobila nätoperatörer. Det är ett ytterligare ändamål med den föreliggande uppfinningen att upprätta en arkítektonisk och affärsmässig referensmodell med hänsyn till aktörer, roller, relationer och vanliga användningssätt, s k use cases, i enlighet med systemet, anordning och förfarande i samband med de ovan beskrivna ändamålen med uppfinningen.

SAMMANFATTNING AV UPPFINNINGEN De ovanstående ändamålen, bl a, uppnås i enlighet med uppfinningen genom tillhandahållande av ett system, förfarande och anordning för att tillhandahålla single sign-on tjänster till en användare som har åtkomst till utvalda tjänsteleverantörer, där användaren har ett abonnemang hos en första mobilnätsoperatör.

Telekommunikationssystemet innefattar ett första mobilnät tillhörande en första mobilnätsoperatör, åtminstone ett andra mobilnät som tillhör en andra mobilnätsoperatör och åtminstone en av ett flertal tj änsteleverantörer för att tillhandahålla tjänster till abonnenter hos de mobila nätoperatörema så snart abonnenter har autentiserats för den åtminstone ena tjänsteleverantören av en autentiseringsmyndighet.

I enlighet med en aspekt av den föreliggande uppfinningen, är en första mobilnätsoperatören och minst en andra mobilnätsoperatören anpassade eller tillhör en cellulär sanmianslutning av mobilnätsoperatörer som verkar som autentiseringsmyndighet.

Vidare innefattar systemet en autentiseringsleverantör som tillhör det första mobila nätet som den enda medlemmen av sammanslutningen som har rätt att autentisera användaren mot den åtminstone ena tjänsteleverantören; och en autentiseiingsmellanhand som tillhör ett andra mobilnät och som är anordnat att verka som ingång till sammanslutningen från de tjänsteleverantörer som har en överenskommelse med den andra mobilnätsoperatören i 10 15 20 25 30 527 706 A n ä» . .. J.. t detta syfte. I det följande kommer en överenskommelse av detta slag att hänvisas till som en inträdesöverenskommelse.

Det betyder att telekommunikationssystemet innefattar medel för att dirigera om en användare som har tillgång till en tjänsteleverantör, där användaren har ett abonnemang med en första mobilnätsoperatör, mot en autentiseringsmellanhand hos en andra mobilnätsoperatör som har en sådan överenskommelse med tjänsteleverantören, och medel för att dirigera om användaren som har tillgång till autentiseringsmellanhanden mot en autentiseringsleverantör för användarens första mobilnätsoperatör, s k home (hemmanät). Dessutom innefattar telekommunikationssystemet medel för att utföra en användares s k homeupplösning vid autentiseringsmellanhanden för att tillåta tjänsteleverantören att begära validering av en autentiseringsförsäkran för den användare från autentiseringsleverantören som tillhör det första mobilnätet.

I synnerhet tillåter telekommunikationssystemet direkt tillgång till autentiseringsleverantören hos den första mobilnätsoperatören, utan att involvera en autentiseringsmellanhand, från de tjänsteleverantörer som har sådana överenskommelser med den första mobilnätsoperatören. I detta syfte innefattar telekommunikationssystemet vidare medel för att dirigera om en användare som har åtkomst till en tjänsteleverantör mot en autentiseringsleverantör hos användarens första mobilnät, d v s home (hernrnanät), utan att involvera en autentiseringsmellanhand, där tjänsteleverantören har en sådan överenskommelse med den första mobilnätsoperatören i det s k home (hemmanät). Vidare kan en sådan tjänsteleverantör begära validering av en autentiseringsförsäkran för den användaren från autentiseringsleverantören utan att involvera en autentiseringsmellanhand.

Generellt innefattar det ovannämnda systemet medel för att utfärda en single sign-on- autentiseringsbegäran från en användare som har åtkomst till en tjänsteleverantör mot en autentiseringsleverantör i den cellulära sammanslutning som är ansvarig för autentisering av användaren för den tjänsteleverantören, där användaren är en abonnent i den cellulära nu g I a 0 n n. c 10 15) 20 25 30 527 706 9 sammanslutningen, och medel för att presentera en mottagen autentiseringsartifakt till tjänsteleverantören.

Ett förfarande föreslås också av den föreliggande uppfinningen för att tillhandahålla single sign-on-tjänster till en användare som har åtkomst till utvalda tjänsteleverantörer, där användaren har ett abonnemang med en första mobilnätsoperatör, och varje vald tjänsteleverantör är förbunden med en andra mobilnätsoperatör. Detta förfarande ' innefattar stegen: (a) upprätta en förtrolig autentiseringsrelation mellan de första och andra mobilnätsoperatörerna, och på så sätt skapa en sammanslutning av mobilnätsoperatörer; (b) omdirigera en åtkomstbegäran som alstras-av 'användaren från den valda tjänsteleverantören mot det cellulära nätet för den första mobilnätsoperatören; (c) alstra vid en autentiseringsleverantör hos den första mobilnätsoperatören, där användarens åtkomstbegäran omdirigeras, en autentiseringsförsäkran som är giltig för användaren som har åtkomst till tjänsteleverantören, och returnera en artifakt för försäkran tillbaka till användren; (d) begära verifiering av autentiseringsförsälcran, som inkluderas i artifakten som presenteras av användaren, från tjänsteleverantören till autentiseringsleverantören hos den första mobilnätsoperatören; (e) accepterande av tjänsteåtkomst till användaren vid mottagande av en framgångsrik verifikationsrespons hos tjänsteleverantören.

I båda fallen, d v s det ovan nämnda telekommunikationssystemet och förfarandet, identifieras en användare mellan en autentiseringsleverantör och en tjänsteleverantör med en delad identitet, oberoende av autentiseringsidentiteten som används mellan 10 15 20 25 30 527 706 lO användaren och autentiseringsleverantöreri i d-n cellulära sammanslutningar., och oberoende av användarens identitet som används mellan användaren och tjänsteleverantören.

Inom telekommunikationssystemet, vilken också tar aktiv del i det ovanstående förfarandet, finns en autentiseringsmellanhand som innefattar första gränssnittsorgan för kommunikation med en användare som har ett abonnemang hos en första mobilnätsoperatör, och andra gränssnittsorgan för kommunikation med en tjänsteleverantör som är förbunden med en andra mobilnätsoperatör. Dessa första och andra gränssnittsorgan kan ses som skapandes en mellanhandskanal för att möjliggöra autentiseringsmellanhanden att omdirigera användaren till användarens hemmanät (home), resp. att lösa upp användarens hemmanät (home) för tjänsteleverantören. En sådan autentiseringsmellanhand kan innefatta en s k web front end som inkluderar de ovan nämnda första och andra gränssnittsorgaiien med användare resp; tjänsteleverantör.

Dessutom innefattar också autentiseringsmellanhanden lagringsplats för alla autentiseringsleverantörer i den cellulära sammanslutningen enligt principen per mobilnätsoperatör, där varje mobilnätsoperatör som är inkluderad i den cellulära sammanslutningen, och organ för att hämta användarens hemmarelaterade (home) adressdata ur lagringsutrymmet. Vidare innefattar autentiseringsmellanhandens web front end också organ för att erbjuda public key infrastructure tjänster (PKI-tjänster) till de tj änsteleverantörer som är anslutna till den mobila nätoperatören som äger autentiseringsmellanhanden för att uppfylla säkerhets- och hemlighetsrelaterade krav hos den cellulära sammanslutningen, för att på så sätt fullgöra ytterligare ett syfte med den föreliggande uppfinningen.

Också inom telekommunikationssystemet, ochtagandes aktiv del i det ovanstående förfarandet, finns det en autentiseringsleverantör som innefattar en frontkanal och en tillbakakanal.

Frontkanalen hos autentiseringsleverantören inkluderar en web front end som innefattar första gränssnittsorgan för att möjliggöra en autentiseringssession mellan en användare 10 15 20 25 30 527 706 CIO IC' Û z g: :o 2 '.: .UU- .IO- fo. sun: nu o u z g : 2: ' ' ° 0' o u , , . . . . . no u o c u u n g , n , . . : c n u u q . no a; 0100 g ll och autentiseringsleverantören. Denna frontkanal innefattar vidare en sessionshanterare och lagringsutrymme för att hantera sessionsstatus för användaren, och en s k front end autentiseringsserver för att utföra en specifik autentiseringsmekanism för användaren.

Tillbakakanalen hos denna autentiseringsleverantör inkluderar en protokollbindning som innefattar andra gränssnittsorgan för att utväxla information som hänför sig till användarautentiseringsförsäkran mellan autentiseringsleverantören och en tjänsteleverantör som användaren har åtkomst till. Denna tillbakakanal innefattar vidare en säkerhetsförsäkran i en Mark-up Language motor för att alstra en autentiseringsförsäluan för en användare, och lagringsutrymme för autentiseringsförsälcran. Dessutom finns det också tillhandahållet ett mellanliggande arbetsorgan mellan frontkanalen och tillbakakakanalen för att alstra och lagra en autentiseringsförsäkran för en användare.

Som en ytterligare fördel med att ha ovanstående system, förfarande och anordning, nämligen autentiseringsmellanhanden och autentiseringsleverantören, tillhandahålls ett förfarande för att åstadkomma affärer varvid åtminstone två mobila nätoperatörer är anpassade till eller på annat sätt utgör del av en sammanslutning av mobilnätsoperatörer, på så sätt upprättande en autentiseringsrelation som är förtrolig inom sammanslutningen för att stödja single sign-on-tjänster. Sammanslutningen verkar som en autentiseringsmyndighet mot de tjänsteleverantörer som erbjuder tjänster till abonnenter till mobilnätsoperatörer som är inkluderade i samrnanslutningen, där varje tjänsteleverantör är förbunden med en mobilnätsoperatör inom sammanslutningen för åtkomst av sammanslutningen. I detta förfarande för att genomföra affärer, bidrar varje mobilnätsoperatör med sitt eget nät och tjänsterna som tillhandahålls av dess anslutna tj änsteleverantörer, och varje nät innefattar en autentiseringsleverantör för autentisering av abonnenter i ett sådant nät och en autentiseringsmellanhand för omdirigering av de anslutna tjänsteleverantörerna till en autentiseringsleverantör som är ansvarig för att autentisera en viss användare inom sammanslutningen. Vidare är varje tjänsteleverantör inom affársförfarandet anordnad för att erbjuda tjänster till abonnenter inom vilken som helst mobilnätsoperatör som är inkluderad i sammanslutningen. Tjänsteleverantören kan 10 15 20 25 30 527 706 12 ha åtkomst till sammanslutningen genom en välkänd airentis-ringsmflknhand i en mobilnätsoperatör som har en sådan överenskommelse med tjänsteleverantören och således har en förtrolig autentiseringsrelalion med sammanslutningen.

KORT BESKRIVNING AV RITNINGAR Särdragen, ändamålen och fördelarna med uppfinningen kommer att förtydligas genom att läsa beskrivningen tillsammans med de därtill hörande ritningarna, i vilka: FIG. 1 schematiskt representerar den arkitektoniska och affärsrelaterade referensmodellen av en cellulär sammanslutning för single sign-on-tj änster.

FIG. 2 visar ett förenklat sekvensdiagrarn som representerar processen som följs för att autentisera en användareoclrauktorisera åtkomst till en- tjänst som erbjuds av en tjänsteleverantör i ett grundläggande scenario där tjänsteleverantören har en affärsöverenskommelse med mobilnätsoperatören som har ett abonnemang för en sådan användare.

FIG. 3 visar ett annat förenklat sekvensdiagrarn som representerar processen som följs för att autentisera en användare och auktorisera åtkomst till en tjänst som erbjuds av en tjänsteleverantör i ett mer allmänt scenario. I detta scenario, har tjänsteleverantören en affärsöverenskommelse med en mobilnätsoperatör som är skild från den som har abonnemanget för en sådan användare, där båda mobilnätsoperatörer är inkluderade i en cellulär sammanslutning.

FIG. 4 presenterar allmänt en exemplifierande intern arkitektur och huvudgränssnitt som involverar en användare, en tjänsteleverantör, en autentiseringsmellanhand, och en autentiseringsleverantör.

FIG. 5A visar en första sekvens (I) av åtgärder när en användare har åtkomst till en autentiseringsleverantör (authentication provider (AP)) genom en s k frontkanal för att 10 15 20 25 30 527 706 oooøuo u 0 I a nu sanne; . 3 nu oo coon o n n o ' - ' e. an: O I U n , oc coon .

Q oun- I 0 coca 13 initiera en ny autentiseringsprocess eller för att aktivera en försäkringsprocess om en giltig autentisering hade utförts tidigare.

FIG. SB visar en andra sekvens (II) av åtgärder som utförs för att autentisera en användare som inte tidigare har autentiserats genom en s k frontkanal vid en AP, och med hjälp av en s k autentiserings back end (i det följande hänvisad till som "auth. B/E").

FIG. SC visar en tredje sekvens (HI) av åtgärder som utförs för att fullgöra en försäkransprocess när en användare visar sig tidigare ha autentiserats, och därför har en aktiv session.

FIG. 6 presenterar en schematisk komposition som, genom att inkludera referenserna i Fig. 5A till SC, visar sekvensen av åtgärder som utförs mellan en användare, en tjänsteleverantör och en autentiseringsleverantör för autentisering av en sådan användare som hade åtkomst till tjänsteleverantören utan att tidigare ha autentiserats.

FIG. 7A presenterar en schematisk sammansättning som, genom att inkludera referensema i Fig. 5A och SB, visar sekvensen av åtgärder som utförs mellan en användare och en autentiseringsleverantör under en isolerad autentisering av en sådan användare.

FIG. 7B presenterar en schematisk sammansättning som, genom att inkludera referenserna i Fig. 5A och SC, visar sekvensen av åtgärder som utförs mellan en användare, en tjänsteleverantör och en autentiseringsleverantör för användaren, som redan har autentiserats, och har åtkomst till tjänsteleverantören.

FIG. 8 illustrerar en mer detaljerad utföringsform av vissa steg som framgår i Fig. 3 i enlighet med en föredragen arkitektonisk modell.

FIG. 9 illustrerar en mer utförlig utföringsform av några andra steg som också återfinns i Fig. 3 i enlighet med en föredragen arkitektonisk modell. 10 15 20 25 30 527 706 14 FIG. 10 visar en exemplifierande relation mellan SSO_auth_ID, SSO_MAIN_ID och SHARED_ID identiteter som hanteras vid en autentiseringsleverantör.

DETALJERAD BESKRIVNING AV FÖREDRAGNA UTFÖRINGSFORMER Det följande beskriver aktuella föredragna utföringsformer av organ, förfaranden och system för att bygga upp en sammanslutning av mobilnätsoperatörer (MNO) som agerar som en autentiseringsmyndighet, eller betrodd tredje part, gentemot förbundna tjänsteleverantörer (SP) som erbjuder tjänster till abonnentema hos någon MNO i sammanslutningen. Dessa föredragna utföringsformer beskrivs i enlighet med en arkitektonisk och affärsmässig referensmodell som tillhandahålls av uppfinningen i termer av aktörer, roller, relationer och grundläggande användningssätt (use cases).

I enlighet med en aspekt av den föreliggande uppfinningen, tillhandahålls en cellulär sammanslutning för single sign-on (FSSO) tjänster. Fig. l presenterar den arkitektoniska och affärsmässiga referensmodellen som beskrivs ovan i termer av aktörer, roller, relationer och några exemplifierande användningssätt med hänsyn tagen till en första sammanslutning (FSSO-1).

Aktörer i referensmodellen i Fig. 1 är användare (User@MNO-A, User@MNO-C), tjänsteleverantörer (SP-l, SP-2) och abonnenters home site, där den senare är mobila nätoperatörer (MNO-A, MNO-B, MNO-C) som innehar abonnentemas abonnemang. I syfte med den föreliggande uppfinningen, är en användare en mobil abonnent som är försedd med en s k subscriber identity module eller med en WAP identity module (SIM/WIM) och med en web/Wap browser; en tjänsteleverantör är målet där en tjänst som begärs av en användare inhyses; och en home site är en mobilnätsoperatör som innehar användarens abonnemang.

Roller som spelas inom ramen för referensmodellen i Fig. l är användare ((User@MNO- A, User@MNO-C), destinationssite, autentiseringsmellanhand (authentication broker 5 10 15 20 25 30 527 706 15 (AB)) och autentiseringsleverantör (authentication provider (AP)). En användare är i detta sammanhang en klient som begär en tjänst från en SP; en destinationssite är en site som har möjlighet att leverera en given tjänst till en klient, i allmänhet en SP genom en MNO som också kan spela denna roll för vissa tjänster; en autentiseringsmellanhand 1, 2 är en medlem av sammanslutningen (FSSO-1) som är avsedd att agera som instegspunkt till sammanslutningen för förbundna SP'er (SP-l, SP-2); och en autentiseringsleverantör 4, 5, 6 är en medlem av sammanslutningen (FSSO-1) avsedd för att äga användardata och den enda som har möjlighet att autentisera och tillhandahålla användarinformation till destinationssiten. I synnerhet, har alltid en SP (SP-1, SP-2) åtkomst (SP-100, SP-200) till sammanslutningen genom dess förbundna AB 1, 2. I syfte att förenkla, betraktas inte SP'er som medlemmar av sammanslutningen, utan refereras således till som förbundna enheter. fUr ett affärsmässigt perspektiv., bidrar inte endast varje särskild MNO (MNO-A, MNO= ' ^ B, MNO-C) till sammanslutningen med sitt eget cellulära nät men också med ett antal förbundna SP'er (SP-1, SP-2) med vilka den har undertecknat särskilda överenskommelser. Dessa förbundna SP'er kan alltid ha åtkomst (S-100, S-200) till sammanslutningen via autentiseringsmellanhanden 1, 2 för en särskild MNO (MNO-A, MNO-B) med vilken varje SP (SP-l, SP-2) har ingått en sådan överenskommelse. Detta är särskilt viktigt, eftersom cellulära operatörer skulle kunna vara benägna att upprätthålla upprättade affarsöverenskommelser med SP'er efter att ha ingått i eller skapat en sammanslutning (FSSO-l, FSSO-2). Vidare kan en nätoperatör öka tjänsterna av hos resp. SP'er på marknader där de har starka positioner, vilket skulle kunna vara fallet för en cellulär multionationell sammanslutning där tjänsteleverantörer tenderar att ingå tjänstenivåöverenskommelser (service level agreements (SLA)) med lokala operatörer.

Den logiska grunden bakom denna referensmodell ur ett affarsperspektiv beror på det faktum att det ger lika möjligheter för mobila operatörer vid uppbyggande, eller vid inträde i sammanslutningen, eftersom en medlem i sarnmanslutningen alltid utgör autentiseringsleverantör gentemot sina egna abonnenter. Dessutom, fast inte 10 15 20 25 30 527 706 än: än: E g 0.: .aa .u- se' n.. u o i o o n I n :li :an-.øg :nancy to oo g.. o g . . . g 0 o o o q , 'I N nan o 16 nödvändigtvis, kan en medlem i sammanslutningen också utgöra autentiseringsmellanhand gentemot abonnenter från andra medlemmar av sammanslutningen för dess förbundna SP'er.

Mer specifikt är en autentiseringsmellanhand 1, 2 ansvarig för att lösa upp användarens home site. Det betyder att AB är ansvarig för att tillhandahålla en förbunden SP med tillräcklig information för att möjliggöra utbyte av användardata mellan den MNO som innehar abonnemanget för en användare och SP'n. Så snart användarens home site har lösts upp, blir det möjligt för AB att omdirigera användaren till användarens home site.

Dessutom och valbart, kan en AB erbjuda public key infrastructure (PKI) tjänster till dess förbundna SP'er för att kunna följa säkerhets- och hemlighetskraven som är karakteristiska för mobila nätoperatörer. ~ ~0lika relationer i referensmodellen i Pig. -1 förtjänar särskilda förklaringar föreytterligare beskrivning av arkitektoniska enheter och gränssnitt, och rationalen bakom aktuella föredragna utföringsformer. I detta avseende har en användare (U ser@MNO-A) (User@MNO-C) en förtrolig relation (R-l 10, R-120) (R-320) med sin home site (MNO- A) (MNO-C). När användaren är registrerad med en SP (SP-1) (SP-2), finns det en direkt förtrolig relation (R-110) (R-120, R-320) liksom mellan båda användarna (User@MNO- A) (User@MNO-C) och SP (SP-1) (SP-2). I syfte att bringa klarhet och för att förenkla relationerna mellan SP'er och samfundet, har det bedömts att var och en av SP'er (SP-1) (SP-2) har en enstaka förtrolig relation (SP-100) (SP-200) med en och endast en medlem i sammanslutningen, nämligen en AB 1, 2, av en mobil nätoperatör (MNO-A) (MNO-B) med vilken SP har en ingången affarsöverenskommelse.

Därför gäller att när en användare (USER@MNO-A, User@MNO-C) vill använda en. cellulär SSO-tjänster vid en given SP (SP-1, SP-2), omdirigera SP'n automatiskt användarens begäran via SP'ns instegspunkt till den cellulära sarmnanslutningen, nämligen en AB l, 2, till en site inom sammanslutningen, nämligen en AP 4, 6 som på riktigt sätt kan hantera användarens begäran. Detta undviker att SP'n tar komplicerade beslut om vart användaren bör omdirigeras. Detta förenklar också väsentligen 10 15 20 25 30 527 706 17 interaktionen mellan en SP och sammanslutningen, och minimera påverkan på SP'er och således öka deras vilja att stå i förbindelse med sammanslutningen. I en mer generell och ett mer verkligt scenario kan en SP (SP-Z) ha en förtrolig relation med olika sammanslutningar, som t ex en cellulär sammanslutning (FSSO-1) och en e- bankssammanslutning (FSSO-2).

I en arman utföringsfonn av den föreliggande uppfinningen, behöver en SP (SP-1) som är förbunden med en särskild MNO (MNO-A) inte gå genom en AB 1 av en sådan MNO för att ha åtkomst till AP 4 i den MNO som har abonnemanget för användaren (User@MNO- A) som har begärt en tjänst i en sådan SP (SP-1)..Detta är särskilt fördelaktigt för en förtrolig relation (R-110) mellan en MNO (MNO-A) och en förbunden SP (SP-l), och i synnerhet optimerar detta nätåtkomst och prestanda.

~ Utan direkt koppling till denna andra utföringsform, och i allmänna ordalag gäller att alla home sites som vill spela rollen av autentiseringsmellanhand har en förtrolig relation med alla medlemmar i sammanslutningen eftersom de också är medlemmar av sammanslutningen. Som förklarats ovan, har en SP möjlighet att omdirigera alla användare till dess instegspunkt, nämligen en cellulär operatör (MNO) eller en home site, inom den cellulära sammanslutningen. Därför behöver autentiseringsmellanhanden (AB) veta om alla sammanslutna home sites.

Emellertid känner en AB i allmänhet inte till användarna i varje home site av sammanslutningen, eftersom detta erfordrar att varje AB har möjlighet att befolka alla användare i sammanslutningen, vilket erfordrar tillhandahållande av ytterligare organ för användarkapacitet och tillgänglighetsstyrning. Det är dock möjligt genom att läsa igenom de aktuella föredragna utföringsformerna som beskrivs i enlighet med uppfinningen, att det kommer att inses att ett unikt eller reducerat antal AB'er 1, 2 försedda med dessa ytterligare organ för användarens kapacitet och tillgänglighetsstyrning, liksom med databasfaciliteter för ett stort antal abonnenter, kan vara lämpligt för en viss typ av cellulär sammanslutning. T ex kan en sådan cellulär sammanslutning vara en 10 15 20 25 30 527 706 18 sammanslutning som innefattar ett flertal nationella MNO'er som tillhör ett globalt företag med faciliteter spridda över världen.

Två huvudsakliga representativa användarsätt skulle kunna beskrivas med hänvisning till ett scenario som presenterades i Fig. 1 och för vilka mer precisa detaljer förklaras ytterligare i exempliñerande utföringsformer ur en arkitektonisk synvinkel.

Ett första användningssätt kan vara en användare (User@MNO-A) som har åtkomst till vissa tjänsteleverantörer (SP-1), såsom exempelvis en bokhandelstjänsteleverantör, varvid tjänsteleverantören (SP-1) är förbunden med den cellulära SSO-sarnrnanslutningen (FSSO-1) genom en särskild mobilnätsoperatör såsom MNO-A. Som visas i Fig. 2, startar processen som följs för att autentisera en sådan användare och auktorisera sådana tjänster när en abonnent hos en MNO-A (User@MNO-A) begär åtkomst (C-21) till en bokhandclstjänsteleverantör (SP- 1). Givet att denna SP har en affärsöverenskomrnelse med MNO-A, och därvid med den cellulära sammanslutningen som MNO-A tillhör till (FSSO-l), omdirigerar SP-1 (C-22) begäran till MNO-A's home site. Vid mottagande vid MNO-A home site av användarens begäran för åtkomst av SP-tjänsten (C-23), presenterar användaren sin egen MNO-A-identitet, t ex med en cookie. I detta skede kan två olika utföringsformer, som redan har kommenterats vara tillämpliga. Mer i detalj fastställer antingen MNO-A som agerar som en autentiseringsmellanhand intemt att MNO-A också är autentiseringsleverantör för den användaren, eller AB och AP vid MNO-A som båda är involverade som i ett mer generellt användningssätt, som kommer att beskrivas i det följande.

Under förutsättning att användaren inte hade autentiserats redan vid MNO-A, utförs autentiseringsproceduren. Om användaren redan var autentiserad,.presenterar han en cookie till MNO-A för att tillåta MNO-A att kontrollera statusen för en särskild användares session. Autentiseringen är inte specifik för varje SP förutom om SP'n erfordrar en specifik autentiseringsmekanism att bli utförd. MN O-A skapar (C-24) en autentiseringsförsäkran för den användaren specifikt och adresserar denna till SP'n. Sedan skickas en artifakt som hänför sig till användarens autentiseringsförsältran och troligtvis 10 15 20 25 30 527 706 19 inkluderar annan autentiseringsinformation tillbaka (C-25) till användaren. Artifakter är av engångsslag för användning och är endast giltig för den specifika SP som den skickats till. Användaren själv presenterar (C-26) denna artifakt till SP-1. SP'n verifierar sedan att källan för artifakten är giltig och begär (C-27) den användarens autentiseringsförsäkran som hänför sig till home siten (MNO-A). MNO-A skickas tillbaka (C-28) den fullständigare användarens försäkran med den erforderliga användardata som inkluderar åtminstone autentiseringsinfonnation. SP-1 analyserar således användarens försäkran och litar på autentisexingen som utförts av användarens home site (MNO-A). Därefter informerar SP-l (C-29) användaren om acceptansen för tjänsteåtkorrist.

Ett andra användningssätt kan vara en användare (User@MNO-A) som har åtkomst till vissa tjänsteleverantörer (SP-2), som exempelvis en tjänsteleverantör av researrangemang. En sådan tjänsteleverantör (SP-Z) är således förbunden med den cellulära SSG-sammanslutningen (FSSO-l) genom en viss cellulär operatör såsom MNO- B, varvid användaren är en abonnent av en annan cellulär operatör (MNO-A) som också är medlem av sarnmanslutningen. Som visas i Fig. 3, följs processen för att autentisera en sådan användare och auktorisera sådan service genom en början då en abonnent hos en MNO-A (User@MNO-A) begär åtkomst (C-21) till en tjänsteleverantör som en researrangörstjänsteleverantör (SP-2) som ett exempel. Denna SP-2 har en affärsöverenskommelse med MNO-B att erbjuda SSO-tjänster till sina användare och till de användare tillhörande de andra medlemmarna av den cellulära sammanslutningen (MNO-A, MNO-C). När SP-2 mottar (C-21) användarens begäran om SSO, omdirigerar SP-2 (C-22) begäran till MNO-B-siten, eftersom nämnda MNO-B är den enda instegspunkten för denna SP till sammanslutningen. Således spelar MNO-B rollen av autentiseringsmellanhand i detta användningssätt och mottar (C-33) en användares omdirigering från SP-2. I syfte att förenkla för SP'n, behöver inte SP'n tjäna till alla home sites i sammanslutningen och därför skickas ingen information om användarens home site i omdirigeringsmeddelandet. I nästa läge begär MNO-B (C-34) användarens home site- nanm. Det har i denna referensmodell betraktats att användarens identitet endast är känd vid hans home site. Ett alternativ är delandet av användar-identiteter inom den cellulära 10 15 20 25 30 527 706 20 sammanslutningen, men emellertid leder detta till behovet av en stor central registerenhet med motsvarande uppgifter att hantera.

Som svar på begäran (C-34) svarar användaren tillbaka (C-35) med hans home site-namn till MNO-B-siten, nämligen till den aktuella autentiseringsmellanhanden (2). Sedan omdirigerar autentiseringsmellanhanden (AB) (C-36) användaren till hans home site, vilket betyder MNO-A. Därefter följer att användaren begär åtkomst (C-23) för SP-2 till hans home site. På samma sätt som i det tidigare användningssättet, gäller att om användaren inte redan har autentiserats vid MNO-A, utförs (C-24) autentiseringsproceduren och artifakt som hänför sig till användarens försäkran med autentiseringsinformationen skickas tillbaka (C-25) till användaren. I detta skede har den användaren möjlighet att presentera (C-26) denna artifakt till SP-2. Sedan måste SP-2 verifiera källan för artifakten och lösa upp användarens home. SP-Z begär (C-37) denna informationfrån AB (2). AB (2) skickar tillbaka-(C-BS) användarens home-, upplösningssvar så att SP-2 kan kontakta (C-27) användarens home site (MNO-A) för att få användarens försäkran som hänvisas till. MNO-A skickar tillbaka (C-28) den fullständiga användarens försäkran med den erforderliga användardata som inkluderar åtminstone autentiseringsinforrriation. Sedan analyserar SP-2 användarens försäkran och litar på autentiseringen som utförs av användarens home site. Därefter tillåter SP-2 (C- 29) användaren att få åtkomst till tjänsten.

Efter att ha presenterat en översikt av den arkitektoniska och affärsmässiga referensmodellen i termer av aktörer, roller, förtroliga relationer, och några exemplifierande användningssätt som illustreras i Fig. 1-3, kommer ytterligare detaljerade utföringsfonner att introduceras med hänvisning till en föredragen arkitektur som är lämplig för att stödja sammanslutna enstaka sign-on (FSSO) tjänster vid var och en av de mobilnätsoperatörer (MNO) som inlduderas i en sammanslutning av ett flertal MNO.

En sådan arkitektur beskrivs med hänvisning till de extema gränssnitt mellan medlemmar i sammanslutningen, tjänsteleverantörer och användare. Dessa gränssnitt inkluderar ett 10 15 20 25 30 527 706 21 gränssnitt mellan en användare, eller snarare användarutrustning (user equipment (UE)), och autentiseringsmellanhanden (i det följande UE-AB i/f); ett annat gränssnitt mellan användaren eller UE och autentiseringsleverantören (i det följande UE-AP i/f); ett annat gränssnitt mellan tjänsteleverantören och en autentiseringsleverantör (i det följande SP- AP i/f); och ytterligare ett gränssnitt mellan tjänsteleverantören och autentiseringsmellanhanden (i det följande SP-AB i/f).

Dessa gränssnitt, eller kombinationer av dessa tillhandahåller kanaler för kommunikation mellan de olika enheterna som är involverade, intema och extema i sammanslutningen.

Dessa kanaler, som avbildas i Fi g. 4, tillhandahåller basen för en lämplig arkitektur.

Således tillåter UE-AB i/f AB att orndirigera användaren till den AP som har ansvar för hans autentisering. Detta gränssnitt stödjer en sådan omdirigering, t ex genom att användaren förser AP med namnet till den AB och AB översätter detta till en -: instegspunkt till AP-siten. Vem som helst som är skicklig inom området skulle enkelt inse andra tillvägagångssätt eller tekniker för att erhålla ett likvärdigt resultat. Detta kommunikationsgränssnitt är en del av en s k "mellanhandskanal (AB)" (1, 2) i home siten.

UE-AP i/f stödjer en autentiseringssession mellan båda aktörer, användaren och autentiseringsleverantören 4, 5, 6. Så snart den är autentiserad, omdirigeras användaren till SP med någon slags bevis eller referenser. Detta kommunikationsgränssnitt hänvisas i till som "framkanal (AP)" 4' i home siten.

SP-AP ilf används huvudsakligen för att utbyta användarinforrnation såsom autentisering, attribut, auktorisering, och försäkringar. Denna kommunikation är genomskinlig för användaren, och refereras i det följande till såsom "tillbakakanal (AP)" 4' i home siten.

SP-AB i/f stödjer upprättandet av tillbakakanalen varvid exempelvis AB översätter käll- ID som finns i artifakten vid instegspunkten i användarens AP- eller PKI-stöd. Detta gränssnitt är också del av den s k “mellanhandskanalen (AB)" l, 2 i home siten. 10 15 20 25 30 Således visar också Fig. 4 funktionella komponenter som en MNO kan stödja för att bli en AP och en AB i en F-SSO-lösning. Som visas i denna figur, kan arkitekturen också betraktas som innefattande en framkanal, en tillbakakanal och en mellanhandskanalvy.

Således kan en autentiseringsleverantör 4, 5, 6 betraktas som innefattande en framkanal 4' och en tillbakakanal 4". Framkanalen är avsedd för att styra autentiseringen av en användare och för att hantera en mastersession mellan användaren och AP. En väsentlig del av styr-logiken som krävs för att få F-SSO-tjänsten att fungera är belägen i enheterna för framkanalen. Tillbakakanalen är avsedd för att hantera en direkt kommunikation mellan SP och AP för att utbyta användarinformation. Mellanhandskanalen är ansvarig för att stödja adressupplösningsbehoven hos SP och användaren.

Beträffande den tidigare nämnda mastersessionen, måste ytterligare detaljerade hänsyn introduceras med avseende på hanteringav sessionen. I detta avseende gäller att när en användare begär en F-SSO-tjänst, måste åtskilliga sessioner skapas och bibehållas enligt följande: - En mastersession mellan användaren och AP. Så snart AP autentiserar en användare, skapar AP en session och lämnar en krypterad cookie i användarens browser för efterföljande autentiseringsfrågor.

- En tjänstesession mellan en användare och SP för att ha möjlighet att använda tjänstema som erbjuds vid SP. Cookies skulle också kunna användas för hanteringen av denna session.

AP behöver hålla ordning på tjänstesessionerna som upprättats mellan användare och varje SP. Av denna anledning gäller i enlighet med en aspekt av den föreliggande uppfinningen och som visas i Pig. 4, att AP innefattar en SSO-sessionshanterare 41 som, företrädesvis är belägen vid framkanalen, och samarbetar med tillbakakanalen och är sammankopplad med en AP web front end 42 som är belägen vid framkanalen likaså.

Vidare inkluderar AP en sessionsdatabas 43 för lagring och upprätthållande av sådan 10 15 20 25 30 527 706 n o 0 Q I c n 23 information. och sessionsdatabasen är företrädesvis belägen vid framkanalen och är sammankopplad med SSO-sessionshanteraren 41.

Före introduktionen av en mer detaljerad beskrivning av aktuella föredragna utföringsforrner för användningssätten som presenteras ovan och avbildats med hänvisning till Fig. 2 och Fig. 3, kommer de olika användaiidentifierarna som olika aktörer hanterar i denna arkitektoniska modell att beskrivas.

I detta avseende, måste användare presentera entydiga identiteter till fina autentiseringsleverantörer för att utföra en SSO-tjänstebegäran, en s k "single sign-on autentiseringsidentitet" (i det följande benämns en sådan SSO_auth_ID), och vilken kan ha åtminstone någon av de följande formaten i syfte att fungera i den föreliggande uppfinningen: - MSISDN/IMSI, vilket tillhör åtkomst till och från en mobiltelefon - User@domain eller user@realm, d v s user@rrmo.com - Användarnamn (sträng av tecken) Autentiseringsleverantören (AP) kan administrera ett flertal av SSO_auth_ID för varje användare, men behöver definiera en s k "huvudsaklig enstaka sign-on-identitet" (i det följande kallas denna SSO__MAIN_ID) för varje användare som korrelerar med ett flertal av SSO_auth_ID. Denna SSO_auth_ID är avsedd för operatörändamål, och mer specifikt för AP, och dess format bestäms slutligen av operatören, vilket betyder att den kan eller behöver inte överensstämma med en SSO_auth_ID som tillhör användaren. Ä andra sidan, gäller att intemetrelaterade användare har en stor variation av användaridentiteter med olika tjänsteleverantören Användare kan vilja behålla aktuella olika identiteter per tjänsteleverantör för åtkomst av konton vid varje site. I syfte enligt den föreliggande uppfinningen kan en sådan identitet hänvisas till som "tjänsteleverantörs användaridentitet" (i det följande hänvisad till som SP_user_ID) och representerar 10 15 20 25 30 24 identiteten för en användare vid en särskild tjänsteleverantör (SP). Denna SP_user_ID har betydelse mellan en ägande användare och en särskild SP.

De tidigare styckena beskriver SSO_MAIN_lD för en användare som har en korrelerande nyckel till åtminstone en SSO_auth_ID som på unikt sätt autentiserar en användare vid användarens hemoperatör, nämligen vid en AP, och beskriver den SP_user_ID som identifierar användaren vid en viss tjänsteleverantör. I ett allmänt scenario matchar inte SSO_MAIN_ID, SSO_auth_ID, och SP_user_ID varandra, och en användare vill inte bli försedd med någon av de andra aktörernas identiteter. I detta fall kan användaren vara känd för SP och för AP med en identitet som delats mellan båda, den s k SHARED_ID.

Denna SHAREDJD kan antingen vara permanent eller temporär beroende på det specifika scenariot som avses. Denna identitet kan anses vara en ogenomskinlig hantering som används av SP och AP för att hänvisa till samma användare.

Således gäller i enlighet med en aspekt av den föreliggande uppfinningen, att en autentiseringsleverantör korrelerar SSO_auth_ID, SSO_MAIN_ID och SHAREDJD medan en tjänsteleverantör korrelerar SP_user_ID och SHARED_ID. En exemplifierande relation mellan dessa identiteter visas i Fig. 10 på ett icke begränsande sätt. Sättet som dessa identiteter administreras på av de olika aktörerna, liksom hur dessa identiteter är länkade till varandra, är inte ytterligare beskrivet i samband med beskrivningen av den föreliggande uppfinningen.

I enlighet med den arkitektoniska modellen som beskrivs ovan och illustreras i Fig. 4, tillhandahålls ytterligare detaljerade utföringsforrner för särskilda aspekter av användningssätt som beskrivs ovan med hänvisning till sekvenser i Fig. 2 resp. 3. Som tidigare nämnts för dessa användningssätt, gäller att när en användare begär (C-23) en SSO-autentisering för hans home site för att få tillgång till en SP, kan olika åtgärder erfordras beroende på huruvida eller inte användaren tidigare hade autentiserats.

Således gäller att genom att inkludera tre sekventiella uppsättningar åtgärder (Sekvens I, II, och III) vilka resp. har avbildats i Fig. 5A till Fig. SC, beskriver utföringsfonnen i 10 15 20 25 30 527 706 25 Fi g. 6 detaljer i användningssättet i Fig. 2 i den arkitektoniska modellen i Fig. 4, medan användaren har åtkomst till en SP som ännu inte har autentiserats av hans hemnät.

Mekanismen i Fig. 6 påbörjas när en användare får åtkomst (C-21) till en SP, och omdirigeras (C-22) till hans home site. Sedan visar den första sekvensen (I) i Fig. 5A att användaren utfärdar en begäran (C-23') om SSO-autentisering med http från hans egna webserver. Användaridentifieringen skulle kunna göras av en krypterad cookie (C-23"), om det finns en lagrad i användarens webagent från en tidigare SSO-session som har ägt rum tidigare. Krypteringen av cookien rekommenderas för att undvika att avslöja användaridentiteten, SSO_MAIN_ID, i fall någon annan erhåller en sådan cookie, antingen genom att fysiskt ha åtkomst till datorn som används för SSO-sessionen eller genom olika script som är avsedda att stjäla cookies från webbrowsers. Eftersom cookien genereras och krypteras av AP, och sedennera, avkrypteras också med hjälp av AP, är krypteringsalgoritmen och nyckelhanteringerr helt och hållet upp till AP. Användarens webbrowser inte förstå innehållet i cookien. I syfte att säkra denna process och undvika stöld av cookies i nätvägar till Webservern, skulle förbindelsen alltid kunna göras över en säker http-länk, d v s https. Användaridentiteten som skall lagras i den cookien bör vara den som valts som SSO_MAIN_ID. Det skulle vara lämpligt att använda en identitet som skiljer sig från den för MSISDN eller IMSI i syfte att hemlighålla.

Mer i detalj, dirigeras användarens webbrowser till den s k web front end 42 (i fortsättningen web F/E) som är belägen vid AP-frarnkanalen. Den första gången användaren har åtkomst till den, laddas en plug-in automatiskt ned med den mjukvara som implementerar klientsidan av webtjänsten för autentisering, såsom ett enkelt objektâtkomstprotokoll (simple object access protocol (SOAP)) klient. Därefter upprättar web F/E gränssnitt (C-500) SSO-sessionshanteraren 41 för att fastställa om det finns en aktiv session som är förknippad med den relevanta IMSI, eller med andra användaridentiteter som används i liknande syfte. I det föreliggande fallet, kommer det inte att vara någon session aktiv i detta skede, eftersom användaren inte tidigare hade autentiserats. 10 15 20 25 30 527 706 26 Proceduren i Fi g. 6 fortsätter med den andra sekvensen (Il) som visas i Fig. SB varvid SSO-sessionshanteraren 41 informerar (C-501) web F/E att det inte finns någon aktiv session. Således informeras användaren om att hans autentisering erfordras (C-502). När användaren kommer till web F/E i AP-frarnkanalen, kan han använda (C-503) som skall vara autentiserad via SIM-kortet, bland de olika autentiseringsmekanismema som finns tillgängliga för användaren, och sedan framkallar SOAP-klienten en sådan tjänst. Notera att SOAP-klienten kan ha laddats ned efter att användaren har valt denna autentiseringsmekanism i stället för innan, utan att påverka skyddsomfânget för uppfinningen. När användaren vill bli autentiserad med SIM-kortet, antas det att identiteten som skall presenteras (C-505) till web F/E är IMSI, som lagrasts i SIM-kortet.

IMSI bör företrädesvis skickas i SOAP-begäran under förutsättning att dialogen utförs på en säker förbindelse, nämligen https, utan att riskera att bryta mot säkerhetskraven. SSO- sessionshanteraren kontakteras (C-506) åter och, vid detektering att användaren» inte har "upprättat en aktiv session, verkar den som RADIUS-klient och begär åtkomst (C607, C- 508) till en autentisering, auktorisering och beräkning (authentication, authorization and accounting (AAA)) server 44. Under förutsättning att en SIM-baserad autentisering har valts, används IMSI som tillämpar identitet och kapslas in i ett attributvärdepar (attribute value pair (AVP)) hos ett utvidgningsbart autentiseringsprotokoll (extensible authentication protocol (EAP)) och i användarnarrmet AVP.

Vid detta skede, och beroende på vilken autentiseringsmekanism som skall användas, kan AAA-servem 44 begära (C-509, C-510) att bli försedd med ett autentiseringsifrågasättande till en back end autentiseringsserver 72 (i det följande benämnd "B/E auth. server"). Denna "B/E auth. server" nås företrädesvis via RADIUS- meddelande vilkas vidareledning skulle kunna göras i termer av den möjliga delen av en nätåkomstidentifierare (network access identifier (NAI)). SSO-sessionshanteraren verkar således som en RADIUS-klient och kan modifiera en sådan verklig del av NAI. Så snart "B/E auth. servern" har mottagit åtkomstbegäranmeddelandet som inkluderar användarens autentiseringsidentitet och uppgifter i EAP APV, kan "B/e auth. servem" erfordra ytterligare uppgifter (C-510 till C-517), vilken process involverar flera EAP-tur- och returresor. 10 15 20 25 30 Ice o 0 u n 0 n I n n o 0 0 en al Oost o 27 Så snart AAA-servern 44 framgångsrikt har autentiserat användaren, skickar den ett åtkomstacceptsmeddelande tillbaka (C-518) SSO-sessionshanteraren. SSO- sessionshanteraren 41 måste nu skapa en ingång för den användaren i sessionsdatabasen, inkuderande SSO_auth_ID och SSO_MAIN_ID. Om SSO-sessionshanteraren inte redan känner till SSO_MAIN_ID, skickar den en förfrågan (C-519) till en identitetshanterare i 70 genom att förse SSO_auth_ID som upplåsningsnyckel för den användaren. Ytterligare fördelar kan uppnås genom att ha en gemensam dirigeringstjänst (common directory service (i det följande hänvisad till som CDS)) för att lagra SSO_MAIN_ID's, och för att förse dem (C-522) till SSO-sessionshanteraren vid en begäran via identitetshanteraren (C-520, C-521). I detta läge skapar SSO-sessionshanteraren 41 en ingång, nämligen en session, för den användaren i sessionsdatabasen 43 genom att inkludera den särskilda SSO_auth_ID som användes under en sådan användarautentisering och SSO_MAIN_ID.

Så snart denna ingång har skapats i SSO-sessionshanteraren,imåste ytterligare logik i web F/E som inte visas i Fig. SB bibehålla sessionens tillstånd mellan efterföljande http- begäran, t ex genom att skicka en cookie till användarens webbrowser.

Det kommer att inses att under denna autentiseringsprocess har det inte funnits någon relation med AP-tillbakakanalen och inga försäkringar har ännu alstrats. Endast en ny session har skapats för en viss användare, inkluderande SSO_MAIN_ID, SSO_auth_ID, en vald autentiseringsmekanism, och adressinformation som en IP-adress, eller en MSISDN som tillhör användaren.

På liknande sätt som sekvens II, fortsätter processen i Fig. 6 med den tredje sekvensen (Ill) som visas i Fig. 5C. SSO-sessionshanteraren 41, hämtar efter att ha haft en giltig session för en viss användare (C-SSO, C-55 l) identiteten från identitetshanteraren 70 för den användare hos den motsvarande tjänsteleverantören (SP), nämligen en SHAREDJD.

Denna SP är den som har skapat den initiala begäran, genom att omdirigera användaren till hans home autentiseringsleverantör (AP). Fastän det inte visas i Fig. SC, lagras denna SHARED_ID och den motsvarande SP för vilken en sådan identitet används i nu on oo Icon n 0 0 I c 0 c o c ao 0 u 0 o 0 0 10 15 20 25 30 527 706 000000 0 0 0 I 00 000000 0 0 0000 000 0 0000 0 0 0 0 0000 28 sessionsdatabasen 43 som är förknippad med mastersessionsinsteget för denna användaren.

Så snart den ovan beskrivna identitetsmappningen har utförts, anropar SSO- sessionshanteraren 41 (C-552) en tjänst i en motor 45 för säkerhetsförsäkrande mark-up- språk (security assertion mark-up language (SAML)), för att alstra en autentiseringsförsäkran för den givna SHARED_ID och för den givna tjänsteleverantören. Försäkran inkluderar annan relevant data, såsom datum och tid när autentiseringsprocessen skedde, och den därmed förknippade säkerhetsstyrkan hos den verkliga autentiseringsmekanismen. Försäkran lagras (C-553) i försäkransdatabasen 46, som troligtvis indexeras med en försäkransreferens. Således ges försäkran en "försäkranshänvisning" för att på unikt sätt identifiera denna senare.

Försäkranshänvisningen är krypterad i enautentiseringsartifakt vid SAML-motom, 'vilken returneras (C.-554) till SSO-sessionshanteraren för vidare ingivning via AP web F/E (C-555) till användaren (C-25).

En sådan artifakt returneras företrädesvis till användaren kryperad som en del av URL, nämligen en parameter. Samtidigt, omdirigeras användarens webbrowser tillbaka till ursprunglig URL som skickades till SP. I verkligheten är denna information erhållen som en parameter i den URL som mottogs vid den första omdirigeringen från SP till AP.

Därför gäller att ursprunglig URL som kommer från SP, målkällan, bör ha lagrats vid AP web F/E.

Därefter presenterar användaren artifakten (C-26) till den ursprungligen kontakterade SP.

SP tar artifakten, och efter att ha avkodat, utvinns försäkranshänvisningen och identiteten hos AP som utfärdat försäkran. SP använder denna information för att upprätta en SAML-dialog (C-27) med AP-tillbakakanalen4", och begär den ursprungliga försäkran, genom att presentera artifakten i SAML-meddelandet som är en begäran om försäkran.

När SAML-motom 45 i AP-tillbakakanalen mottar begäran om försäkran (C-27), hämtar den försäkran (C-556, C-557) från försäkransdatabasen 46. signerar det digitalt och skicker det sedan tillbaka till SP (C-28). 10 15 20 25 30 29 SP kontrollerar sedan giltigheten hos försäkran, företrädesvis genom att utnyttja dess egna publika nyckelinfrastruktur (public key infrastructure (PKI)) eller, i ett mer generiskt fall som kommer att förklaras ytterligare, genom att utnyttja PKI hos en förtrolig autentiseringsmellanhand.

Så snart försäkran har visat sig giltig vid SP och ursprunget har bedömts vara att lita på, kan SP fortsätta att analysera innehållet i försäkran och upprätthålla hans lokala principer i enlighet med autentiseringsuppgifter som inkluderas i försäkran. Slutligen informeras användaren (C-29) om acceptansen av åtkomst till tjänst.

Det kommer att inses att den ovanstående beskrivningen med hänsyn till Fig. 6, med fördragna utföringsforrner som förklarats i Fig. 5A till SC, tillhandahåller arkitektoniska detaljer för användningssätt som tidigare har presenterats rned' hänvisning till Fig. 2.

Dessa arkitektoniska detaljer är avsedda att förstås på ett förklarande sätt men inte på ett begränsande sätt.

Genom att inkludera de tre uppsättningama efter varandra av åtgärder (sekvens I, II och III) vilka resp. avbildas i Fig. 5A till Fig. SC, utföringsfonner i Fig. 7A och 7B också beskriver detaljer för användníngssättet i Fig. 2, med särskild hänvisning till den arkitektoniska modellen i Fig. 4 varvid användaren har åtkomst till en SP som redan har autentiserats av hans hemnät. Mer specifikt presenterar Fig. 7A en självständig autentisering av en användare gentemot en autentiseringsleverantör vid hans hemnät, medan Fig. 7B presenterar åtgärder som utförs när användaren har åtkomst till en SP, och när han en gång har omdirigerats till sitt hemnät betraktas användaren redan vara autentiserad och har en giltig session som fortfarande är vid liv.

Mekanismen i Fig. 7A startar direkt med den första sekvensen (I) som visas i Fig. SA varvid användaren utfärdar en http-begäran (C-23') om SSG-autentisering från hans egen webserver som följs upp, om sådan finns tillgänglig, av en användaridentiñering med en krypterad cookie (C-23") som skickas mot web F/E vid AP-framkanalen som i den 10 15 20 25 30 527 706 30 motsvarande sekvensen som visas med hänvisning till användningssättet i Fig. 6. Därefter etableras ett web F/E-gränssnitt (C-500) med SSO-sessionshanteraren 41 för att kontrollera om det finns en aktiv session som står i förbindelse med den användaren.

Sekvensen fortsätter och följer den andra sekvensen (II) som visas i Fig. 5B varvid autentiseringsproceduren, som troligtvis valts av användaren utförs. I synnerhet gäller att så snart SSO-sessionshanteraren 41 har skapat en session för användaren i sessionsdatabasen 43, i verkligheten genom att inkludera de särskilda SSO__auth__ID som utnyttjas och SSO_MAIN_ID, informerar SSO-sessionshanteraren AP web F/E varvid ytterligare logik som inte visas i Fig. SB upprätthåller sessionstillståndet för därefter följande http-begäran. Slutligen, som visas i Fig. 7A godkänner AP web F/E (C-70) en framgångsrik sign-on i riktning mot användarens webbrowser.

Denna användaren som redan är autentiserad kan begära (C-21) en tjänsteåtkomst till en' SP. Denna SP, under förutsättningarna som beskrivits* ovan för användningssättet i Fig. 2. « varvid en autentiseringsmellanhand inte erfordras, omdirigerar (C-22) användaren till hans home site. Sedan, och följandes sekvensen i Fig. 5A, får användaren än en gång åtkomst till den särskilda AP web F/E 42 från vilken en indikation utfärdas mot SSO- sessionshanteraren 41 för att kontrollera huruvida eller inte en giltig session fortfarande är vid liv. Därefter tar SSO-sessionshanteraren 41 troligen i samarbete med en sessionsdatabas 43 reda på att en session fortfarande existerar för den användaren. Sedan, som visas i den tredje sekvensen (III) och som visas i Fig. SC, hämtar SSO- sessionshanteraren 41 (C-550, C-551) en SHARED_ID att användas för den SP, beordrar (C-552, C-553, C-554) alstrande och lagring av en försäkran för SI-IAREDJD och dess inkludering i en autentiseringsartifakt. Denna artifakt returneras via web F/E (C-555) till användaren (C-25) och presenteras (C-26) som i användningssättet mot SP. SP kontrollerar sedan den ursprungliga försäkran (C-27, C-556, C-557, C-28) med AP- tillbakakanalen 4", och slutligen erbjuds (C-29) acceptans för tjänsteåtkomst för den användaren.

Detaljerade utföringsformer för användningssättet i Fig. 2 har beskrivits i de föregående styckena och särskiljer ett första beteende i Fig. 6, där användaren har åtkomst till en SP 10 15 20 25 30 31 utan att ännu ha autentiserats, från ett andra beteende i Pig. 7A och 7B där användaren först autentiseras och sedan ges acceptans för en tjänst.

I enlighet med en annan aspekt av den föreliggande uppfinningen, beskrivs nu användningssättet som tidigare har förklarats med hänvisning till Pig. 3 ytterligare med hänsyn till den arkitektoniska modellen som visas i Pig. 4. I synnerhet görs skillnad på utföringsforrner som härrör från inkluderingen av en autentiseringsmellanhand och motsvarande nya gränssnitt.

Således som illustreras i Pig. 3, uppstår ett andra användningssätt när en användare (User@MNO-A) har åtkomst till en viss tjänsteleverantör (SP-Z) som är associerad med en cellulär SSO-sarnmanslutning (FSSO-1) genom en viss cellulär operatör såsom MNO- B, medan användaren är en abonnent hos en annan cellulär operatör (MNO-A), vilken . också är en medlem av sammanslutningen. ídetta andra användningssättbehövs en » autentiseringsmellanhand (AB) i enlighet med en aspekt av den föreliggande uppfinningen för mottagning av omdirigeringen från SP (SP-Z), som löser upp användarens home site, och omdirigering till MNO där användaren hör hemma.

I detta avseende visar Pig. 8 åtgärderna som skall utföras mellan användaren och AB före omdirigering av användaren till en lämplig autentiseringsleverantör (AP) vid användarens home site. Mer speciñkt visar Pig. 8 dessa åtgärder med hänvisning till den arkitektoniska modellen som illustreras i Fig. 4 medan Fig. 3 inte tar i beaktande alla särskilda anordningar som en AB skulle kunna innefatta. Således gäller att när en användare utfärdar en autentiseringsbegäran för SP-2 (C-33) mot autentiseringsmellanhanden (AB) som i Pig. 3, finns det i verkligheten en http- omdirigering som mottas i en AB web F/E 21 vid en mellanhandskanal 2 som Fig. 8 visar. Sedan, begärs en användares home site-namn från AB web P/E (C-34, C-35).

Denna begäran kan göras t ex genom att presentera en websida för användaren med alla AP i sarnmanslutningen, varvid användaren endast behöver klicka på logon för hans hemoperatör. I nästa skede erhålls en URI för användarens home site (C-84, C-85) från en autentiseringsleverantör (AP) databas 22. Slutligen omdirigerar (C-36) AB web P/B 10 15 20 25 30 527 706 32 2l användarens http till lämplig AP vid hans home site. AB kan kvarlämna en cookie i webbrowsern hos användaren för att undvika ytterligare förfrågningar av användarens home och relaterade förfrågningar i efterföljande iterationer. Flödessekvensen fortsätter med en SSO-autentiseringsbegäran (C-23, C-23', C-23") mot AP web F/E 42 som beskrivits ovan med hänvisning till användningssätt som illustreras i Fig. 6 eller Fig. 7A och 7B.

Fig. 9 visar âtgärdema som skall vidtagas mellan en tjänsteleverantör och en AB för en användares home-upplösning för att hitta var försäkran bör giltiggöras. Mer specifikt, visar Fig. 9 dessa åtgärder med hänvisning till den arkitektoniska modell som illustreras i Fig. 4, varvid Fig. 3 inte tar hänsyn till alla särskilda anordningar som en AB skulle kunna tänkas innefatta. Efter att användaren har presenterat (C-26) artifakten till SP (SP- 2) som illustreras i Fi g. 3 och 9, begärs (C-37) en användares home-upplösning till AB.

- En sådan begäran mottas vid AB tveb 'F/E 21 vid rnellanhandskanalen 2. Sedan beg-är (C- 91, C-92) AB web F/E 21 från en AP-databas 22 om en URI för AP vid home siten som sedan skickas tillbaka (C-38) till SP. SP, genom att företrädesvis utnyttja DNS-tekniker, upplöser home URI och validerar slutligen (C-27, C-28) autentiseringsförsäkran, vilken tidigare erhölls (C-23, C-24, C-25) som visas i Fig. 3 eller, mer specifikt och som beskrivits ovan med hänvisning till användningssätt som illustreras i Fig. 6 eller Fig. 7A och 7B. Giltiggörandet av autentiseringsförsäkran (C-27, C-28) utfärdas från SP (SP-2) mot SAML-motom 45 troligtvis via en protokollbindning (protocol binding 47), vilken på fördelaktigt sätt är placerad mellan SAML-motom och SP. Denna protokollbindning 47 med dess komponenter är anordnade för att knyta upp en XML-instans från ett transportprotokoll, som t ex httms för att ta ett exempel, och vidarebefordra det via SAML-motorn, SP har således rätt att göra vilken som helst slags förfrågan som definieras i SAML-standarder.

Med hänsyn till kontrollen av giltighet hos försäkran i detta senaste användníngssätt, behöver inte SP implementera all PK-komplexitet, och inte heller behöver det lokalt installera certifikat från alla autentiseringsleverantörer i sammanslutningen, utan endast 527 706 33 certifikatet för dess förtroliga enhet i sammanslutningen, nämligen certifikatet för AP som är värd för denna autentiseringsmellanhand.

Naturligtvis är många modifieringar och varianter av den föreliggande uppfinningen möjliga i ljuset av de ovanstående beskrivningarna. Det är därför uppenbart att uppfinningen inom skyddsomfånget för det beskrivna konceptet kan förverkligas på annat sätt än såsom specifikt har beskrivits.

Claims (30)

10 20 25 30 527 706 34 Patentkrav

1. l. Telekommunikationssystem som tillhandahåller single sign-on tjänster till en användare som har åtkomst till utvalda tjänsteleverantören där användaren har ett abonnemang hos en första mobilnâtsoperatör, där systemet innefattar: - ett första mobilnät och åtminstone ett andra mobilnät; - minst en av ett flertal tjänsteleverantör-er vilka tillhandahåller tjänster till abonnenter i mobilnäten då abonnentema har autentiserats mot nämnda tjänsteleverantör av en autentiseringsbefogerillet; ' kännetecknat av att en eellulâr sammanslutningen av mobilnâtsoperatörer verkar som autentiseringsbefogenhet, där den cellulära sammanslutningen inkluderar det första mobilnätet och det andra mobilnätet, och innefattande: - en autentiseringsleverantör som tillhör det första mobilnätet som den enda medlemmen av sanmianslutningen som har rätt att autentisera användaren mot tjänsteleverantören; och - en autentiseringsmellarihand som tillhör det andra mobilnâten och som är anordnad att verka som ingång till sammanslutningen fi-ári de resp. tjänsteleverantörer som har inträdesöverenskommelser med operatören för det andra mobilnätet.

2. Telekommunikationssystem enligt krav 1, vidare innefattande: - medel för omdirigeríng av användaren, då användaren aeoessar en tjänsteleverantör, mot en autentiseringsmellanhand för en andra mobilnätsoperatör som har en inträdesöverenskommelse med tjänsteleverantören; och 10 20 25 30 527 706 35 - medel för omdirigering av användaren, då användaren aeeessar autentiseringsmellanhanden, till autentiseringsleverantören vid användarens hemnät.

3. Telekommuníkatíonssystem enligt krav 2, vidare innefattande medel för utförande av användarens home-upplösning vid en autentiseringsmellanhand för en andra mobilnätsoperatör som har en inträdesöverenskommelse med en tjänsteleverantör, för att tillåta tjänsteleverantören att begära godkännande av en autentiseringsförsäkran för användaren till en autentiseringsleverantör i ett första mobilnät.

4. Telekommuníkatíonssystem enligt krav 3, vidare innefattande: - medel för utfärdande av en single sign-on autentiseringsbegäran från användaren, när användaren accessar en tjänsteleverantör, mot en autentiseringsleverantör som âr ansvarig för autentisering av användaren mot tjänsteleverantören, där användaren är en abonnent i den cellulära sammanslutningen; och - medel för att presentera den mottagna autentiseringsartifakten för tjänsteleverantören.

5. Telekommuníkatíonssystem enligt krav 1, varvid autenfiseringsleverantören som tillhör den första mobilnätsoperatören kan bli aecessad direkt, utan att involvera en autentiseringsmellarilrand, från tjänsteleverantörer som har inträdesöverenskommelser med den första mobilnätsoperatören.

6. Telekommuníkatíonssystem enligt krav 5, vidare innefattande medel för att omdirigera användaren, när användaren accessar en tjänsteleverantör, mot en autentiseringsleverantör mot användarens hemma mobilnâtsoperatör, utan att involvera en autentiseringsmellarihand, när tjänsteleverantören har en intrâdesöverenskommelse med användarens hemma mobilnätsoperatör.

7. Telekommuníkatíonssystem enligt krav 6, varvid en tjänsteleverantör som har en överenskommelse med den första mobilnätsoperatören kan begära godkännande av en 10 20 25 30 527 706 36 autentiseringsförsälaan för en användare till en autentiseringsleverantör för den första mobilnätsopcratören utan att involvera autentiseringsmellanhanden.

8. Telekommunikationssystem enligt krav 7, vidare innefattande: - medel för utfärdande av en single sign-on autentiseringsbegäran från användaren, när användaren accessar en tjänsteleverantör, mot en autentiseringsleverantör som är ansvarig för att autentisera användaren mot tjänsteleverantören, där användaren är en abonnent i den cellulära sammanslutningen; och - medel för att presentera den mottagna autentiseringsartifakten för tjänsteleverantören.

9. Telekommunikationssystem enligt krav 1, varvid användaren identifieras mellan en autentiseringsleverantör och en tjänsteleverantör med hjälp av en delad identitet oberoende av den autentiseringsidentitet som används mellan användaren och autentiseringsleverantören, och oberoende av användaridentiteten som används mellan användaren och den tjänsteleverantören.

10. Telekommunikationssystem enligt krav 9 vidare innefattande åtminstone en av komponenterna i en grupp av komponenter inkluderande: - publik nyckelinfi-asnuktlrr (public key infrastructure) medel för att uppfylla säkerhets- och privacykrav för mobila nät i den cellulära sammanslutningen; - en identitetshanterare för underhåll och hantering av relationer mellan identiteter för användaren under premisser för den cellulära sarnmanslutningen och de identiteter för användaren under resp. prernisser för tjänsteleverantören; - gemensamma dirigeringstjänsteorgan (common directory service) för lagring av användaridentiteter som är tillgängliga genom en single sign-on-huvudidentitet; och 20 25 30 527 706 37 - en tillbakakanalautentiseringsserver som är avsedd för att alstra en autentiseringsförfi-àgan som beror pá en autentiseringsmekanism som väljs av användaren.

11. 1 1. Förfarande för att tillhandahålla single sign-on tjänster till en användare som har åtkomst till utvalda tjänsteleverantören där användaren har ett abonnemang hos en första rnobilnätsoperatör, och där varje utvald tjänsteleverantör är associerad med en andra mobilnätsoperatör, kännetecknat av att det innefattar stegen att: (a) upprätta en förtrolig autentiseringsrelation mellan de första och andra mobilnätsoperatörerna, och på så sätt skapa en sammanslutning av mobilnätsoperatörer; (b) omdirigera en åtkomstbegäran som alstras av användaren från en av tjänsteleverantörerna mot den första mobílnätsoperatören eellulära nät; (c) alstra vid en autentiseringsleverantör hos den första mobilnätsoperatören, till vilken användarens åtkomstbegäran orndirigeras, en autentiseringsförsäkran som är giltig för användaren som har åtkomst till tjänsteleverantören, och retumerande en artifakt för försäkran tillbaka till användaren; (d) begära verifiering av autentiseringsförsälcrari, vilken inkluderas i artifakten som presenteras av användaren, fiàn tjänsteleverantören till autentiseringsleverantören för den första mobilnätsoperatören; och (e) acceptera tjänsteåtkomst till användaren som svar pá mottagning av en godkänd verifieringsrespons vid tjänsteleverantören.

12. Förfarande enligt krav 1 1, varvid de båda första och andra mobilnätsoperatörerna är inkluderade i den eellulära sammanslutningen, och där steget a) hos detta förfarande 20 25 527 706 38 vidare innefattar ett av följande steg beroende på mobilnätsoperatören med vilken den valda tjänsteleverantören är associerad: (al) fastställande av en autentiseringsleverantör för den första mobilnätsoperatören som är ansvarig för användaren, när den valda tjänsteleverantören står i förbindelse med den första mobilnätsopeiatören; eller (a2) omdirigera àtkomstbegäran som alstras av användaren fi-än den valda tjänsteleverantören till en autentiseríngsmellanhand för en andra mobilnätsoperatör, när den valda tjänsteleverantören står i förbindelse med den andra mobilnätsoperatören, där autentiseringsmellanhanden är ansvarig för att fastställa en autentiseringsleverantör för den första mobilnätsoperatören som är ansvarig för användaren.

13. Förfarande enligt krav 1 l, varvid steg b) innefattar stegen att: (bl) motta en single sign-on-autentiseringsbegäran från användaren; (b2) bestännna huruvida eller inte användaren tidigare hade autentiserats; (b3) utföra en förfi-àgan/responsautentiseringsprocedm i enlighet med användarönskemål för användaren som har åtkomst till den valda tjänsteleverantören, under förutsättning att användaren inte tidigare hade autentiserats, och således inte har en giltig session aktiv; och (b4) lagra en försäkran som alstrats för användaren som har åtkomst till den valda tjänsteleverantören. 20 25 527 706 39

14. Flört-farande enlligt krav ll, varvid både den första och andra mobilnätsoperatören är inkluderad i den cellulära sammanslutningen, och steget c) för detta förfarande dessutom innefattar ett av följande steg beroende på mobilnätsoperatören till vilken den valda tjänsteleverantören är förbunden med: (cl) fastställande av en autentiseringslevemntör för den första mobilnätsoperatören som är ansvarig för att godkänna försäkran som presenteras av användaren, när tjänsteleverantören är förbunden med den första mobilnätsoperatören; eller (c2) begärande av upplösning av användarens home site från den utvalda tjänsteleverantören mot en autentiseringsmellanltand för en särskild andra mobilnâtsoperatör, när den andra tjänsteleverantören står i förbindelse med den andra mobilnätsoperatöreri, där denna autentiseringsmellanhand är ansvarig för att fastställa en autentiseringsleverantör för den första mobilnätsoperatören som är ansvarig för att validera försäkran som presenteras av användaren.

15. Förfarande enligt krav l 1, varvid steg d) vidare innefattar stegen att (dl) hämta en lagrad autentiseringsförsäkran för användaren som har åtkomst till den utvalda tjänsteleverantören; och (d2) returnera försäkran med en verífieringsrespons till den utvalda tjänsteleverantören.

16. Förfarande enligt krav l 1, varvid användaren identifieras mellan en autentiseringsleverantör och en tjänsteleverantör med en delad identitet oberoende av den autentiseringsídentitet som används mellan användaren och autentiseringsleverantören, och oberoende av användaridentíteten som används mellan användaren och tjänsteleverantören. 20 25 527 706 40

17. Aiztentiseiingsmellïiliæd i ett telekommunikationssystem som tillhandahåller single sign-on tjänster till en användare som har åtkomst till utvalda tjänsteleverantören där användaren har ett abonnemang hos en första mobilnätsoperatör, och varje utvald tjänsteleverantör associeras med en andra mobilnâtsleverantör, där autentiseringsmellanhanden innefattar: - första gränssnitt för kommunikation med en användare som har ett abonnemang hos en första mobilnätsoperatör; - andra gränssnitt för kommunikation med en tjänsteleverantör associerad med den andra mobilnätsoperatören; och - mellanhandskanal som skapats av de första och andra gränssnitten för att möjliggöra för autentiseringsmellarilianden att orndirigera användaren till användarens hemnät, resp. för att upplösa användarens hemnät för tjänsteleverantören.

18. Autentíseringsmellanlrand enligt krav 17, varvid både användaren och autentiseringsmellanhanden tillhör den första mobilnätsoperatören, och ett antal utvalda tjänsteleverantörer står i förbindelse med den första mobilnätsoperatören.

19. Autentiseringsmellarihand enligt krav 17, vidare innefattande en autentiseringsmellanhands web front end som inkluderar första och andra grflnssnitten för att utgöra gränssnitt mellan användaren resp. en utvald tjänsteleverantör.

20. Autentiseringsmellarihand enligt krav 19, vidare irmefattande lagringsutryrnme för alla autentiseringsleverantörer i den cellulära sammanslutningen på en per mobilnätsoperatörbasis, där varje mobilnätsoperatör är inkluderad i den cellulära sammanslutningen. 20 25 30 527 706 41

21. Autentiseringsmellanharad enligt krav 20, varvid autentiseringsmellarnhandens web front end vidare irmefattar medel för att hämta användarens home-relaterade adresseringsdata ur minnesutrymmet.

22. Autentiseringsmellanhand enligt krav 21, varvid autentiseringsmellanliandens web front end vidare innefattar medel för att erbjuda publika nyekelinfiastuiktiirtjänster (public key infiastructure services) till de tjänsteleverantörer som står i förbindelse med den mobilnätsoperatör som äger autentiseringsmellarllianden, i syfte att uppfylla säkerhets- och privacykmven för den cellulära sammanslutningen.

23. Autentiseringsleverantör inkluderad i ett telekommunikationssystem som tillhandahåller single sign-on tjänster till en användare som har åtkomst till utvalda tjänsteleverantören där användaren har ett abonnemang hos en första mobilnätsoperatör, och varje utvald tjänsteleverantör associeras med en andra mobilnätsoperatör, där autentiseringsleverantören innefattar: - en fiamkanal inkluderande en web fi-ont end som innefattar första gränssnitts för att möjliggöra en autentiseringssession mellan användaren och autentiseringsleverantören; och - en tillbakakanal som inkluderar en protokollbindning som innefattar andra gränssnitt för att utväxla information som relaterar till användarautentiseriiigsförsälcran mellan autentiseringsleverantören och en utvald tjänsteleverantör som användaren har åtkomst till.

24. Autentiseringsleverantör enligt krav 23, varvid fi-arnkanalen dessutom innefattar en sessionshanterare och lagringsutryrnme för hantering av sessionsstatiis för användaren, och en front end autentiseringsserver för att utföra en speeifik autentiseringsmekanism för användaren. 20 25 527 706 42 *zarvid tillbakakanalen för autentiseringsleverantören vidare innefattar en mark-up language motor för sâkerhetsförsälrran (security assertion mark-up language engine) för att alstra en autentiseringsförsâluan för användaren, och lagringsutrymme för autentiseringsförsâlningar.

25. Autentiseririgsleverantër enligt krav 2

26. Autentiseringsleverantör enligt krav 25, vidare innefattande samarbetsorgan mellan framkanal och fillbakakanal för att alstra och lagra en autentiseringsförsäluan för användaren.

27. Autentiseríngsleverantör enligt krav 26, varvid funktionen för samarbetsorganet mellan framkanalen och tillbakakanalen utförs via sessionshanteraren resp. mark-up språkmotom för säkerhetsförsâkran.

28. Autentiseringsleverantör enligt lcrav 27, varvid sessionshanteraren innefattar medel för att hämta fiån en identitetshanterare, med gemensamma dirigeringstjärrsteorgan, relationer mellan identiteter för användaren under cellulära sarnmanslumingens premisser och de identiterema för användaren under resp. premisser för tjänsteleverantören, där identiteterna korrelereras av en single sign-on-huvudidentitet.

29. Autentiseringsleverantör enligt krav 24, varvid front end autentiseringsservem samarbetar med andra enheter i den cellulära sammanslutningen som verkar som en tillbakakanal autentiseringsserver för att tillhandahålla specifik användardata under premisser gällande mobilnätsoperatören.

30. Autentiseringsleverantör enligt krav 29, varvid fiont end autentiseringsservem är en server för autentisering, auktorisering och beräkning, i normalfallet àtkomlig från en nätåtkomstserver i ett cellulärt nät.