Tarvitsetko todella useita vuokralaisia hallitaksesi identiteettijärjestelmääsi?

Nykyään matalan koodin työkalujen ja pilvipalveluiden kypsyyden lisääntyessä, AI-työkalujen käytön nopeutuessa kehittämisen kynnystä lasketaan huomattavasti, ja markkinoille ilmestyy yhä enemmän sovelluksia.

Olipa kyse monimutkaisista tai yksinkertaisista sovelluksista, useimmat sovellukset sisältävät käyttäjän rekisteröintiin ja kirjautumiseen liittyviä skenaarioita, jotta käyttäjät voivat saada vakaampia, turvallisempia ja räätälöidympiä palveluita. Käyttäjän kirjautumis- ja rekisteröitymisongelman ratkaisemiseksi ensimmäinen askel on identiteettijärjestelmän rakentaminen.

Monille kuluttajille suunnatuille sovelluksille niiden identiteettimallit ovat usein suhteellisen yksinkertaisia, tai niissä vaaditaan ehkä vain sähköposti ja salasana. Sovelluksille, jotka ovat nopean kasvun ja uusien käyttäjien houkuttelemisen vaiheessa, tämä riittää; mutta kun sovelluksella on oma liiketoimintamallinsa, yksinkertaisimmillaan, esimerkiksi mainosten tarjoamisessa, on tarpeen tehdä ero tavallisten käyttäjätilien ja mainostajien tilien välillä. Mainostajatilit voivat mukauttaa mainostoimitusten laajuuksia, sisältöjä jne.; kun taas tavalliset käyttäjät voivat vain selata joitakin ilmaisia sisältöjä ja mainoksia jne.

Logto on pilvipohjainen identiteettiratkaisu, ja se tarjoaa myös avoimen lähdekoodin ohjelmistoratkaisun (OSS) samoine ytimineen pilvipalveluiden kanssa niille käyttäjille, joilla on erityistarpeita mukautuksen toteuttamiseen. Logton palvelu on rakennettu monivuokralaisjärjestelmälle, jossa kukin Logton käyttäjä luo oman tilinsä ja voi hallita useita vuokralaisia tilin sisällä. Muiden eri identiteettipilvipalveluiden arkkitehtuuri on samankaltainen, ja jokaisella erilaisella pilvipalvelulla on omat määritelmänsä "vuokralaiselle", joten tässä artikkelissa käsittelemämme vuokralaismalli rajoittuu Logton skenaarioon, ja muilla toimittajilla saattaa olla muita vastaavia käsitteitä.

On huomattava, että Logton monivuokralaismallissa data vuokralaisten välillä (kaikki loppukäyttäjien tiedot) on eristetty, joten Logton käyttäjät voivat hallita loppukäyttäjätilien tietoja liiketoimintatarpeidensa mukaisesti yhdessä Logto-tilissä. Monet muut identiteettipilvipalvelut tukevat vain kutakin tiliä, jolla on yksi vuokralainen, mikä pakottaa käyttäjät, jotka haluavat hallita useita vuokralaisia samanaikaisesti, vaihtamaan usein tilien välillä, mikä johtaa huonoon käyttökokemukseen.

Kaiken tuon jälkeen, kuinka sinun pitäisi valita tilimalli, joka sopii sovelluksellesi? Katsomme täällä kolmea tapausta.

Tapaus 1: Sovellus tarjoaa suoraan palvelua loppukäyttäjille#

Tämän tyyppisten sovellusten identiteettimalli on melko yksinkertainen. Käytetään esimerkkinä musiikin suoratoistosovellusta — hallinnon (Logton käyttäjän "foo", joka on vuokralaisen omistaja tässä tapauksessa ja jolla on olennaisesti hallinnolliset oikeudet) lisäksi on vain loppukäyttäjiä.

Tässä skenaariossa loppukäyttäjät voidaan jakaa kolmeen tyyppiin:

1. Ilmaiskäyttäjä: Voi kuunnella vain ilmaista musiikkia.
2. Maksukäyttäjä: Voi kuunnella ilmaista musiikkia ja luoda omia soittolistoja.
3. Premium-käyttäjä: Maksuttoman musiikin kuuntelun ja soittolistojen luomisen lisäksi voi myös kuunnella HiFi-musiikkia.

Yllä olevassa sovellusskenaariossa tarvitsemme vain kolmen tyyppisiä rooleja (ilmainen, maksu, premium), joista jokaiselle annetaan eri käyttöoikeudet. Joten sen jälkeen, kun loppukäyttäjä kirjautuu sisään, Logto voi päättää, tarjotaanko tiettyjä palveluita (esimerkiksi pääsyä HiFi-musiikkiin) hänelle hänen roolinsa perusteella. Tässä vaiheessa tarvitsemme vain yhden vuokralaisen vaatimusten täyttämiseksi.

Tapaus 2: Verkkokauppasovellus#

Alusta, joka yhdistää kolmannen osapuolen palveluntarjoajat ja loppukäyttäjät, mikä on myös hyvin yleinen 2C-liiketoimintamalli nykyään. On kaksi käyttäjäryhmää, jotka täytyy huomioida - käytetään esimerkkinä verkkokauppasovellusta, he ovat kauppiaat (palveluntarjoajat) ja ostajat (loppukäyttäjät).

Tässä on kaksi tapaa rakentaa identiteettimalli:

1. Aseta ostajat ja kauppiaat saman vuokralaisen alle.

2. Laita ostajat ja kauppiaat kahteen eri vuokralaiseen erikseen.

Helpottaaksemme esimerkin ymmärtämistä oletamme, että ostajat voivat tehdä tilauksia tai tarkastella tuotteen kuvauksia; kauppiaat voivat muuttaa tuotteen hintoja, muuttaa tuotteen kuvauksia ja tarkastella tuotevarastoja. Kauppiaat katsovat tuotteen kuvauksia auttaakseen tunnistamaan ongelmia ja päivittääkseen tuotetietoja ajoissa.

Identiteettimallissa 1 on vain yksi sovellus. Kaikista rekisteröityneistä käyttäjistä tulee ostajia. Jos joku haluaa myydä asioita, hän voi lisätä omia tuotteitaan myyntiin, jolloin tällaiset loppukäyttäjät saavat kauppiasoikeudet ostajan oikeuksien lisäksi hallitakseen omia tuotteitaan.

Identiteettimallissa 2, koska jokaisella vuokralaisella on oma ainutlaatuinen identiteettitieto ja oma erillinen valtuutusportti, jokaisella vuokralaisella on oltava oma erillinen sovelluksensa. Esimerkkitapauksessa olisi ostajasovellus ja kauppiasovellus. Ostajakäyttäjät eivät voi tulla kauppiaiksi, eivätkä kauppiaat myöskään voi tulla ostajiksi. Jos kauppiaat haluavat tarkistaa omien tuotteidensa kuvaukset ostajan näkökulmasta kuten mallissa 1, heidän on toteutettava sama toiminnallisuus kauppiasovelluksessa tai rekisteröitävä ostajasovelluksen tilin tarkastellakseen sitä. Tämä lisää paljon monimutkaisuutta, mutta etuna on, että ostajan ja kauppiaan identiteetit ovat täysin eristettyjä.

Jos kauppiailla on paljon erilaisia tuotteita hallittavana, käyttämällä identiteettimallia 2 ja kehittämällä enemmän erikoistunutta kauppiasovellusta pitäisi olla parempi valinta. Malli 1 sopii enemmän alustoille kuten eBay, jossa kauppiailla ei ole monta tuotetta ja he eivät tarvitse liian monimutkaista tuotteen hallintatoiminnallisuutta.

Tapaus 3: IT-konsulttiyrityksen tekemät sovellukset#

Oletetaan, että on olemassa IT-tekninen konsulttiyritys, jonka asiakkailla ei ole kykyä kehittää IT-järjestelmiä itse, joten heidän on haettava teknisiä palveluja tältä yritykseltä.

Oletetaan, että yrityksellä on kaksi asiakasta, joista yksi on kirjakaupan sisäinen kirjanhallintajärjestelmä, ja toinen asiakas on hotellivarausjärjestelmä.

Kirjakauppiaan näkökulmasta katsottuna en tietenkään halua, että hotellivierailla olisi mahdollisuus kirjautua satunnaisesti minun kirjanhallintajärjestelmääni, koska se olisi hyvin turvatonta. Siksi yksityisyyden suojaamisen näkökulmasta kullekin asiakkaalle on perustettava erillinen vuokralainen, hyödyntämällä vuokralaisen tiedoneristysmekanismia, jotta asiakkaiden tiedot eivät ole nähtävissä muille asiakkaille.

Kuten mainitsimme aiemmin, vaikka sinulla olisi tarve luoda useita vuokralaisia, Logto voi auttaa hallitsemaan useita vuokralaisia yhdellä tilillä, mikä on kätevämpää ja turvallisempaa verrattuna joihinkin muihin palveluihin, jotka vaativat sinua luomaan ja hallinnoimaan useita tilejä itse.

Esimerkkien avulla, jotka on esitetty yllä, olet varmasti selvittänyt, milloin sinun ehdottomasti täytyy luoda useita vuokralaisia, missä skenaarioissa voit olla joko yhdellä vuokralaisella tai useilla vuokralaisilla, ja omien liiketoimintatarpeidesi perusteella valita identiteettimalliratkaisu, joka sopii sinulle parhaiten.

Logto-tiimin tavoitteena on varmistaa, ettei "pitäisikö luoda useita vuokralaisia" ole esteenä millekään liiketoiminnalle. Jos olet epävarma, voiko liiketoimintaskenaarioosi vastata yhdellä vuokralaisella, ole hyvä ja liity Logto-yhteisöön saadaksesi konsultointia. Kysymyksesi saattaa olla myös jonkun toisen kysymys, joten jaa kohtaamasi haasteet kanssamme auttaaksemme parantamaan Logton tuotteiden laajennettavuutta.

Jos valitset identiteettikehystä sovelluksellesi, Logto on kokeilemisen arvoinen. Se tarjoaa heti käyttövalmiin ratkaisun, joka sopii erilaisille liiketoimintaskenaarioille pienistä yrityksistä laajamittaisiin sovelluksiin!