Määritä pääsy tietyille rooleille. Käyttöoikeuden rajoittaminen AuthorizeAttributella
Toistaiseksi olemme osoittaneet vain, kuinka varmistaa, että käyttäjät ovat sitä, mitä he sanovat olevansa, ja kuinka poimia tietoja todennetuista henkilöllisyydestä. Tämä antaa sovelluksille peruskyvyn erottaa käyttäjät toisistaan, mutta se on vain lähtökohta. Luodaksesi todella suojatun verkkosovelluksen, sinun on tunnistettava ne sovelluksen eri paikoissa.
Valtuutus on prosessi sen määrittämiseksi, onko todennetulla käyttäjällä riittävät oikeudet tietyn toiminnon suorittamiseen. Tällainen toiminta voi olla web-sivun pyyntö, pääsy hallinnoituun resurssiin käyttöjärjestelmä(kuten tiedosto tai tietokanta) tai sovelluskohtaisten tehtävien suorittaminen (kuten tilauksen tekeminen tilaustenhallintajärjestelmään tai projektin osoittaminen projektinhallintasovelluksessa, esim. Microsoft Project Palvelin).
Jotkut heistä Windows tarkistaa toteuttaa automaattisesti, kun taas muut voidaan koodata deklaratiivisesti web.config-tiedoston avulla. Jotkut tarkistukset on kuitenkin tehtävä suoraan koodissa IPrincipal-objektia käyttämällä.
URL-valtuutus
Helpoin tapa määrittää käyttöoikeudet on asettaa ne yksittäisille verkkosivuille, verkkopalveluihin ja alihakemistoihin. Ihannetapauksessa verkkosovellusalustan tulisi tukea resurssikohtaista valtuutusta ilman tarvetta muuttaa koodia tai kääntää sovellusta uudelleen. ASP.NET tukee tätä vaatimusta ilmoittavilla valtuutussäännöillä, jotka voidaan määrittää web.config-tiedostossa.
Määrittämäsi säännöt ovat voimassa erityinen moduuli HTTP nimellä UrlAuthorizationModule. Moduuli tarkastelee näitä sääntöjä ja tarkistaa jokaisen pyynnön varmistaakseen, että käyttäjällä ei ole pääsyä resursseihin, jotka on erityisesti rajoitettu.
Tämän tyyppistä valtuutusta kutsutaan URL-valtuutukseksi, koska se ottaa huomioon vain kaksi yksityiskohtaa - käyttäjän suojauskontekstin ja Resurssin URL-osoite, jota käyttäjä yrittää käyttää. Jos pääsy sivulle estetään ja lomaketodennusta käytetään, käyttäjä ohjataan rekisteröintisivulle.
Valtuutussäännöt
Toisin sanoen on olemassa kahdenlaisia sääntöjä: sallia ja kieltää. Voit lisätä niitä niin monta kuin haluat. Jokainen sääntö tunnistaa yhden tai useamman käyttäjän tai roolin (käyttäjäryhmät). Lisäksi voit käyttää verbit-attribuuttia luodaksesi sääntöjä, jotka koskevat vain tietyntyyppisiä HTTP-pyyntöjä (GET, POST, HEAD TAI DEBUG).
Yksinkertainen esimerkki on jo annettu aiemmissa artikkeleissa. Voit estää pääsyn kaikilta anonyymeiltä käyttäjiltä määrittämällä säännön
Tässä tapauksessa kysymysmerkki (?) on jokerimerkki, joka edustaa kaikkia käyttäjiä, joilla on tuntematon identiteetti. Tätä sääntöä käytetään lähes aina todennusskenaarioissa. Tämä johtuu siitä, että muiden tunnettujen käyttäjien pääsyä ei voida estää, ellet ensin pakota kaikkia todentamaan itseään.
Voit käyttää ylimääräistä yleismerkkiä, tähteä (*), joka edustaa kaikkia käyttäjiä. Esimerkiksi seuraava jakso
Tätä sääntöä tarvitaan harvoin, koska se on jo kone.config-tiedostossa. Kun ASP.NET on soveltanut kaikkia web.config-tiedoston sääntöjä, se soveltaa kone.config-tiedoston sääntöjä. Tämän seurauksena jokainen käyttäjä, jolta on nimenomaisesti evätty pääsy, saa sen automaattisesti.
Katsotaan nyt, mitä tapahtuu, jos jakso
Sääntöjä arvioidessaan ASP.NET skannaa luettelon ylhäältä alas. Kun se löytää sopivan säännön, haku pysähtyy. Siksi edellisessä tapauksessa se määrittää, että sääntö
Kun valtuutussäännöt lisätään verkkosovelluksen juurihakemiston web.config-tiedostoon, niitä sovelletaan automaattisesti kaikkiin verkkoresursseihin, jotka ovat osa sovellusta. Jos anonyymit käyttäjät eivät saa kirjautua sisään, ASP.NET tarkistaa todennustavan. Jos lomaketodennus on valittu, ASP.NET ohjaa käyttäjän rekisteröintisivulle.
Seuraavissa osissa opit hienosäätämään valtuutussääntöjä niiden laajuuden määrittämiseksi tarkemmin.
Käyttöoikeuden määrittäminen tietyille käyttäjille
säännöt
Esimerkiksi seuraava valtuutussääntö rajoittaa pääsyn kolmeen käyttäjään. Nämä käyttäjät eivät voi käyttää sivuja, jotka ovat hakemistossa, jossa on nämä merkinnät sisältävä web.config-tiedosto. Kaikki muut todennetut käyttäjät voivat käyttää näitä sivuja:
Voit myös määrittää pilkuilla erotellun nimiluettelon ja estää useiden käyttäjien pääsyn samanaikaisesti. Alla on edellistä esimerkkiä vastaava versio, jossa käytetään vain kahta todennussääntöä:
Huomaa, että kummassakaan tapauksessa järjestyksellä, jossa nämä kolme käyttäjää esiintyvät luettelossa, ei ole merkitystä. On kuitenkin tärkeää, että pääsyn estäminen näiltä käyttäjiltä edeltää sääntöä
Kun rakennetaan suojattuja sovelluksia, on usein parempi antaa nimenomaisesti pääsy tietyille käyttäjille ja ryhmille ja sitten estää pääsy kaikilta muilta (sen sijaan, että estetään pääsy tietyiltä käyttäjiltä, kuten edellisissä esimerkeissä). Alla on esimerkki valtuutussäännöistä, jotka sallivat pääsyn kahdelle käyttäjälle. Kaikkia muiden käyttäjien pyyntöjä ei tyydytetä, vaikka ne on todennettu:
Sinun tulisi kiinnittää huomiota yhteen yksityiskohtaan. Näissä esimerkeissä käyttäjänimen muoto olettaa lomaketodennusta. Tällä todennuksella käyttäjätunnus määritetään, kun RedirectFromLoginPage()-metodia kutsutaan. Tässä vaiheessa myös UrlAuthorizationModule käyttää tätä nimeä ja vertaa sen valtuutussääntöjen luetteloon.
Hallitse pääsyä tiettyihin hakemistoihin
Sovelluksen yleinen suunnittelupäätös on sijoittaa todennusta vaativat tiedostot erilliseen hakemistoon. ASP.NET-määritystiedostojen ansiosta tämä lähestymistapa on helppo toteuttaa. Jätä elementti Muista, että kun lisäät web.config-tiedoston alihakemistoon, se ei saa sisältää muita sovelluskohtaisia asetuksia. Itse asiassa sen pitäisi sisältää vain valtuutustiedot, kuten alla on esitetty: Kahvan asetukset Kun käytät valtuutussääntöjä alihakemistossa, ASP.NET lukee silti valtuutussäännöt päähakemistosta. Erona on, että alihakemiston sääntöjä sovelletaan ensin. Tämä on tärkeää, koska ASP.NET pysähtyy heti, kun se löytää valtuutussäännön. Harkitse esimerkkiä, jossa virtuaalinen juurihakemisto sisältää yhden säännön: ja alihakemisto on toinen sääntö: Tässä tapauksessa käyttäjä dan voi käyttää mitä tahansa resurssia juurihakemistossa, mutta hänellä ei ole pääsyä alihakemiston resursseihin. Jos kumoat nämä kaksi sääntöä, danilla on pääsy vain alihakemiston resursseihin, mutta ei juurihakemiston resursseihin. Mielenkiintoisempaa on, että ASP.NET sallii rajoittamattoman alihakemistojen ja valtuutussääntöjen hierarkian. On esimerkiksi täysin mahdollista, että virtuaalinen hakemisto valtuutussäännöineen, alihakemisto, joka määrittää lisäoikeuksia, ja toinen alihakemisto siinä alihakemistossa, joka määrittää omat sääntönsä. Helpoin tapa ymmärtää valtuutusprosessi tässä tapauksessa on kuvitella kaikki säännöt yhtenä luettelona alkaen hakemistosta, jossa pyydetty sivu sijaitsee. Jos kaikki nämä säännöt käsitellään, eikä vastaavuutta löydy, ASP.NET alkaa lukea valtuutussääntöjä päähakemistosta, sitten tämän hakemiston päähakemistosta ja niin edelleen. - kunnes osuma löytyy. Jos vastaavia sääntöjä ei löydy, ASP.NET soveltaa lopulta sääntöä Tyypillisesti tiedostojen käyttöoikeuksien asettaminen hakemistotasolla on selkein ja helpoin tapa. On kuitenkin mahdollista rajoittaa pääsyä tiettyihin tiedostoihin lisäämällä kuvauksia Sijaintikuvaajat sijoitetaan pääkuvaajan ulkopuolelle Tämä esimerkki avaa pääsyn kaikkiin sovellustiedostoihin paitsi SecuredPage.aspx ja AnotherSecuredPage.aspx, joilla on valtuutussääntö, joka estää anonyymin pääsyn niihin. Jotta sivuston tietoturva olisi helpompi ymmärtää ja ylläpitää, käyttäjät ryhmitellään usein luokkiin, joita kutsutaan rooleiksi. Kun sinun on hallittava yritystason sovellusta, joka tukee tuhansia käyttäjiä, on helppo ymmärtää roolien merkitys. Jos joutuisi määrittelemään käyttöoikeudet jokaiselle yksittäiselle käyttäjälle, se olisi työlästä, vaikeaa muuttaa ja lähes mahdotonta välttää virheitä. Lomakkeiden todennus itsessään ei tue rooleja, mutta jäsenyyden API:n ohella käyttöliittymä on saatavilla ASP.NETissä API-roolit, joka on käyttövalmis sovellusten roolituen ja hallinnan toteutus. Lisäksi, jos et halua käyttää tätä viitekehystä, on melko helppoa luoda oma, joka jakaa käyttäjät sopiviin ryhmiin heidän henkilöllisyytensä perusteella. Kun olet määrittänyt, voit luoda valtuutussääntöjä rooleille. Itse asiassa nämä säännöt näyttävät täsmälleen samalta kuin aiemmin esitetyt käyttäjäkohtaiset säännöt. Esimerkiksi seuraavat valtuutussäännöt estävät pääsyn anonyymeiltä käyttäjiltä ja sallivat sen kahdelle tietylle käyttäjälle (dan ja Alex) ja kahdelle ryhmälle (Manager ja Supervisor). Kaikkien muiden käyttäjien pääsy on estetty: Mieti esimerkiksi, mitä tapahtuu, jos sallit pääsyn ryhmään, joka sisältää tietyn käyttäjän, ja sitten nimenomaisesti estät pääsyn kyseiselle käyttäjälle. Tai päinvastoin - sallimalla pääsyn käyttäjälle nimellä, estät pääsyn ryhmään, johon hän kuuluu. Näissä skenaarioissa voit odottaa, että tarkemmat säännöt (käyttäjäkohtaiset) ovat yleisempiä (ryhmäkohtaisia) etusijalla. Tai voit odottaa, että rajoittavammat säännöt ovat aina etusijalla, kuten Windowsissa on tapana. ASP.NET ei kuitenkaan käytä kumpaakaan näistä lähestymistavoista. Sen sijaan ASP.NET soveltaa vain ensimmäistä täsmäyssääntöä. Tämän seurauksena sääntöjen määrittelyjärjestys on kriittinen.. Katsotaanpa esimerkkiä: Seuraavassa kuvataan, kuinka ASP.NET jäsentää nämä säännöt: Tässä esimerkissä käyttäjälle Alex saa pääsyn riippumatta ryhmistä, joihin hän kuuluu. Kaikilta Vieras-roolin käyttäjiltä evätään pääsy. Jos Alex on Vieras, hänen pääsynsä pysyy avoinna, koska käyttäjäkohtainen sääntö löydetään ensin. Seuraavaksi käyttöoikeus myönnetään kaikille Manager-ryhmän käyttäjille. Ainoa poikkeus ovat ne, jotka sisältyvät sekä johtaja- että vierasryhmiin. Vierassääntö on määritetty aiemmin luettelossa, joten näiltä käyttäjiltä on jo evätty pääsy. Sitten pääsy evätään käyttäjältä dan. Mutta jos dan on Manager-ryhmän jäsen, pääsy pysyy hänelle avoinna. Kaikille Supervisor-ryhmään kuuluville käyttäjille, paitsi niille, joille pääsy on avattu tai suljettu aikaisempien sääntöjen mukaan, myönnetään pääsy. Ja lopuksi pääsy on suljettu kaikilta muilta käyttäjiltä. Muista, että kaikki nämä päällekkäiset säännöt voivat kattaa myös useita hakemistoja. Esimerkiksi alihakemisto voi olla yksityinen käyttäjälle, kun taas ylähakemisto voi olla avoin ryhmänsä käyttäjälle. Tässä esimerkissä käytettäessä alihakemiston tiedostoja käyttäjäkohtaista sääntöä sovelletaan ensin. URL-pohjainen valtuutus on yksi ASP.NET-valtuutuksen kulmakivistä. ASP.NET käyttää kuitenkin myös toisen tyyppistä valtuutusta, jonka monet kehittäjät usein jättävät huomiotta tai jättävät huomiotta. Tämä on moduulin toteuttama tiedostopohjainen valtuutus FileAuthorizationModule. Tiedostopohjainen valtuutus toimii vain, jos käytetään Windows-todennusta. Jos käytät erikois- tai lomaketodennusta, tiedostojen valtuutus ei ole voimassa. Ymmärtääksesi tiedostojen valtuutuksen olemuksen, sinun on ymmärrettävä, kuinka Windows-käyttöjärjestelmä tarjoaa tiedostojärjestelmän suojauksen. Jos kyseessä on NTFS-tiedostojärjestelmä, voit asentaa luetteloita ACL (käyttöoikeusluettelo), joka ilmaisee käyttäjien ja roolien henkilöllisyyden, joille on sallittu tai evätty pääsy yksittäisiin tiedostoihin. FileAuthorizationModule yksinkertaisesti tarkistaa pyydetyn tiedoston käyttöoikeudet Windowsin määrittelemällä tavalla. Jos esimerkiksi verkkosivua pyydetään, FileAuthorizationModule tarkistaa, onko tällä hetkellä todennettulla IIS-käyttäjällä oikeus käyttää vastaavaa .aspx-tiedostoa. Jos näin ei tapahdu, sivukoodia ei suoriteta ja käyttäjä saa viestin pääsyn estämisestä. Uudet ASP.NET-käyttäjät ihmettelevät usein, miksi tiedostojen valtuutus tulisi toteuttaa erillisessä moduulissa ja miksi ei luottaisi käyttöjärjestelmään sen tekemisessä? Ymmärtääksemme FileAuthorizationModulen tarpeen meidän on muistettava, kuinka ASP.NET suorittaa koodin. Jos toisena henkilönä esiintyminen ei ole käytössä, ASP.NET toimii kiinteän käyttäjätilin, kuten ASPNETin, alla. Windows-käyttöjärjestelmä tarkistaa, onko ASPNET-tilillä tarvittavat oikeudet päästä .aspx-tiedostoon, mutta se ei suorita samaa tarkistusta IIS-todennettulle käyttäjälle. FileAuthorizationModule täyttää tämän aukon. Se suorittaa valtuutustarkistuksia nykyisen käyttäjän suojauskontekstin perusteella. Tämän seurauksena järjestelmänvalvoja voi määrittää tiedostojen tai kansioiden käyttöoikeudet ja hallita ASPNET-sovelluksen osien pääsyä. Yleensä on helpompaa ja kätevämpää käyttää valtuutussääntöjä web.config-tiedostossa. Jos kuitenkin haluat hyödyntää paikallisen tai yritysverkon olemassa olevia Windows-oikeuksia, voit tehdä niin. Hyvää iltapäivää, rakkaat ohjelmoijat. Jokin aika sitten julkaistiin upea .NET-kehys webille - ASP.NET MVC 5. Tässä kehyksessä ilmestyi paljon mielenkiintoista. Myös valtuutuksen ja autentikoinnin mekanismi on jälleen muuttunut. Tänään haluan puhua niistä lyhyesti. Vähän tietoa niille, jotka edelleen sekoittavat nämä kaksi termiä. Todennus- Tämä on tosiasioiden tarkistus siitä, kuka yrittää kirjautua järjestelmäämme. Useimmiten todennus toteutetaan kysymällä käyttäjältä käyttäjätunnusta ja salasanaa. Niiden kautta käyttäjä tunnistetaan. Valtuutus- Tämä on tarkistus, jolla tarkistetaan, onko tietyllä käyttäjällä lupa suorittaa tietty toiminto. Karkeasti sanottuna tämä on useimmiten roolimekanismi (esimerkiksi jos tämä on järjestelmänvalvoja, hän voi tehdä mitä tahansa toimia; jos tämä on käyttäjä, hän voi vain lukea viestejä). ASP.NET MVC 5:ssä valtuutuksen ja todentamisen mekanismi on jälleen muuttunut. Nyt sitä käytetään näihin tehtäviin OWIN(The Open Web Interface for .NET) on spesifikaatio, joka määrittelee käyttöliittymän ja kuvaa kaikkien komponenttien välistä vuorovaikutusta. Lyhyesti sanottuna se on abstraktio (väliohjelmisto), joka erottaa todennusvastuut sovelluksesta. OWINin ansiosta ASP.NET MVC 5 sisältää melko paljon hienoa tavaraa. Voit esimerkiksi käyttää heti Facebook- tai google-tunnistusta. Lisäksi voit todentaa melko helposti vkontakten kautta. OWINissa on kuitenkin joitain ongelmia. Pääasia on, että tämä mekanismi on melko uusi, ja verkossa on vain vähän esimerkkejä. Ei ole ollenkaan selvää, kuinka tavallista käyttäjää laajennetaan, kuinka muuttaa oletusarvoisesti luotujen taulukoiden AspNetUsers, AspNetUserRoles, AspNetUserLogins, AspNetUserClaims, AspNetRoles nimiä, miten rooliluokkaa laajennetaan (ja yleensä miten työskennellä roolien kanssa - loppujen lopuksi sellaista esimerkkiä ei aluksi ole) . Aloin itse etsiä vastauksia näihin kysymyksiin. Jonkin ajan kuluttua löysin artikkeleita, jotka kuvaavat vastauksia yllä esitettyihin kysymyksiin. — perustyö todennuksen kanssa. — User-luokan laajentaminen sekä ensimmäiset roolit — Roolien vakioluokan laajentaminen Oppitunnin tarkoitus: Tutki evästeen kautta tapahtuvaa valtuutusmenetelmää, ohjaimen ja ohjainmenetelmän vakiokäyttömääritteiden käyttöä. IPrincipalin käyttö. Luo oma moduuli (IHttpModule) ja oma IActionFilter. Pieni poikkeama: Itse asiassa asp.net mvc:ssä kaikki oppikirjat suosittelevat käyttämään jo keksittyä valtuutusjärjestelmää nimeltä AspNetMembershipProvider, se kuvattiin artikkelissa (pääsy on nyt suljettu), mutta tämä on selitetty "click" näkökulmasta enkä ymmärrä mitä siellä on sisällä." Kun tutustuin asp.net mvc:hen, tämä hämmensi minua. Lisäksi tässä artikkelissa sanotaan, että et voi käyttää tätä palveluntarjoajaa. Ja olen samaa mieltä tästä. Täällä opiskelemme melko syvällisesti kaikenlaisia hankalia asp.net mvc -standarditekniikoita, joten tämä on yksi tärkeimmistä oppitunneista. Palvelin kirjoittaa vastauksen otsikkoon: HTTP/1.1 200 OK Sisältötyyppi: text/html Set-Cookie: nimi=arvo Set-Cookie: nimi2=arvo2; Vanhenee = ke, 09-6-2021 10:18:14 GMT Aseta eväste (/Areas/Default/Controllers/HomeController.cs): Chromessa tarkistamme asennuksen: Evästeiden vastaanottaminen: Tehdään keskeytyskohta ja tarkistetaan: Huomautus: Saat lisätietoja evästeistä seuraavasta linkistä: Aloitetaan. Julkinen käyttöliittymä IAtodentaminen ( /// Käyttöönotto (/Global/Auth/CustomAuthentication.cs): Lopputulos on tämä: kun alustamme pyyntöä, käytämme HttpContext.Request.Cookies-tiedostoa ja alustamme UserProviderin: Var lippu = FormsAuthentication.Decrypt(authCookie.Value); _nykyinenKäyttäjä = new UserProvider(lipun.Nimi, Arkisto); Lisätty valtuutusta varten IRepositoryssa uusi menetelmä IRepository.Kirjaudu sisään. Toteutus SqlRepositoryssa: UserProvider toteuttaa itse asiassa IPrincipal-rajapinnan (jolla on roolien tarkistus ja pääsy IIdentityyn). Julkinen luokka UserProvider: IPrincipal ( yksityinen UserIndentity userIdentity ( get; set; ) #region IPrincipal Jäsenet public IIdentity Identity ( get ( paluu userIdentity; ) ) public bool IsInRole(merkkijonorooli) ( if (userIdentity.User == null) ( return false ; ) return userIdentity.User.InRoles(role) #endregion public UserProvider(merkkijonon nimi, IRepository-tietovarasto) ( userIdentity = new UserIndentity(); userIdentity.Init(nimi, arkisto); ) julkinen ohitusmerkkijono ToString() ( return); userIdentity.Name) UserProvider tietää, että sen IIdentity-luokka on UserIdentity ja tietää siksi User-luokasta, jonka sisällä toteutamme InRoles(role) -metodin: Julkinen bool InRoles(merkkijonoroolit) ( if (string.IsNullOrWhiteSpace(roles)) ( return false; ) var rolesArray = roolit.Split(new ( "," ), StringSplitOptions.RemoveEmptyEntries); foreach (var role in rolesArray) ( var hasRole = UserRoles.Any(p => string.Compare(p.Role.Code, role, true) == 0 if (hasRole) ( return true; ) return false) InRoles-menetelmässä odotamme saapuvan pyynnön resurssille sallituista rooleista pilkulla erotettuna. Eli esimerkiksi "admin, moderator, editor", jos Käyttäjällämme on ainakin yksi rooleista, niin palautetaan arvo "true" (on pääsy). Vertaamme Role.Code-kentän, ei Role.Name-kentän perusteella. Julkinen käyttäjä GetUser(sähköpostimerkkijono) ( return Db.Users.FirstOrDefault(p => string.Compare(p.Email, email, true) == 0); ) Melkein kaikki on valmista. Näytetään CurrentUser BaseControllerissa: Kyllä, tämä ei ole oikein, koska siihen liittyy vahva sitominen. Tehdään siis näin, esittelemme toisen käyttöliittymän IUserProvider , josta vaadimme valtuutetun käyttäjän palauttamista meille: Kernel.Bind Sitten luomme moduulin, joka suorittaa valtuutustoiminnon AuthenticateRequest-tapahtumassa: Kaikki suola on riveillä: auth.HttpContext = konteksti ja konteksti.User = auth.CurrentUser . Heti kun valtuutusmoduulimme saa tiedon kontekstista ja sen sisältämistä evästeistä, se saa välittömästi pääsyn nimeen, sitä käyttämällä se vastaanottaa arkistossa olevat käyttäjätiedot ja palauttaa ne BaseControllerille. Mutta ei kaikkea kerralla, vaan pyynnöstä. Suunnitelma on: Mennä. Lisää Html.Action("UserLogin", "Home") – tämä on osittainen näkymä (eli koodinpätkä, jolla ei ole ulkoasua) – ts. näkyy siellä, missä se on rekisteröity, ei RenderBody()-funktiossa. Hallitse pääsyä tiettyihin tiedostoihin
Määritä pääsy tietyille rooleille
Tiedoston valtuutus
Keksit
Evästeet ovat palvelimen selaimelle lähettämä tieto, jonka selain palauttaa takaisin palvelimelle jokaisen (melkein jokaisen) pyynnön yhteydessä.
Set-Cookie: arvo[; päättyy=päiväys][; domain=domain][; polku=polku][; turvallinen]
Esimerkiksi:
Selain (jos eväste ei ole vanhentunut) jokaisessa pyynnössä:
GET /spec.html HTTP/1.1 Isäntä: www.example.org Eväste: nimi=arvo; nimi2=arvo2 Hyväksy: */*
public ActionResult Index() ( var cookie = new HttpCookie() ( Nimi ="testi_eväste", Arvo = DateTime.Now.ToString("pp.MM.yyyy"), Expires = DateTime.Now.AddMinutes(10), ); Response.SetCookie(cookie) return View();
var cookie = Request.Cookies["testi_eväste"];
http://www.nczonline.net/blog/2009/05/05/http-cookies-explained/ Valtuutus
Meidän tapauksessamme valtuutus perustuu evästeiden käyttöön. Tätä varten tutkitaan seuraavat säännökset:
Luodaan IAuthentication-käyttöliittymä ja sen toteutus CustomAuthentication (/Global/Auth/IAuthentication.cs):
public class CustomAuthentication: IAuthentication ( yksityinen staattinen NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger(); yksityinen const string cookieName = "__AUTH_COOKIE"; julkinen HttpContext HttpContext ( get; set; ) julkinen IRepository (getregository; setregository; IAuthentication Jäsenten julkinen Käyttäjätunnus(merkkijono käyttäjänimi, merkkijono Salasana, bool isPersistent) ( User retUser = Repository.Login(käyttäjänimi, salasana); if (retUser != null) ( CreateCookie(käyttäjänimi, isPersistent); ) return retUser; ) julkinen käyttäjä Kirjautuminen(merkkijono userName) ( User retUser = Repository.Users.FirstOrDefault(p => string.Compare(p.Email, userName, true) == 0); if (retUser != null) ( CreateCookie(käyttäjänimi); ) return retUser; ) private void CreateCookie(merkkijono userName, bool isPersistent = false) ( var ticket = new FormsAuthenticationTicket(1, userName, DateTime.Now, DateTime.Now.Add(FormsAuthentication.Timeout), isPersistent, string.Empty, FormsAuthenokticie. ); // Salaa lippu. var encTicket = FormsAuthentication.Encrypt(ticket); // Luo eväste. var AuthCookie = uusi HttpCookie(evästeenNimi) ( Arvo = encTicket, Expires = DateTime.Now.Add(FormsAuthentication.Timeout) ); HttpContext.Response.Cookies.Set(AuthCookie); ) public void LogOut() ( var httpCookie = HttpContext.Response.Cookies; if (httpCookie != null) ( httpCookie.Value = string.Empty; ) ) yksityinen IPprincipal _currentUser; public IPprincipal CurrentUser ( get ( if (_currentUser == null) ( kokeile ( HttpCookie authCookie = HttpContext.Request.Cookies.Get(cookieName); if (authCookie != null && !string.IsNullOrEmpty(authCookie)) (var.Value) = FormsAuthentication.Decrypt(authCookie.Value); " + esim. viesti); _currentUser = new UserProvider(null, null); ) ) return _currentUser; ) ) #endregion )
julkinen käyttäjätunnus(merkkijono sähköpostiosoite, merkkijonon salasana) ( return Db.Users.FirstOrDefault(p => string.Compare(p.Sähköposti, sähköposti, true) == 0 && p.Salasana == salasana); )
Harkitse UserProvider-luokkaa (/Global/Auth/UserProvider.cs):
Harkitse UserIdentity-luokkaa (/Global/Auth/UserIdentity.cs):
public class UserIndentity: IIidentiteetti ( public User User ( get; set; ) public string AuthenticationType ( get ( return typeof(User).ToString(); ) ) public bool IsAuthenticated ( get ( return User != null; ) ) julkinen merkkijono Nimi ( get ( if (Käyttäjä != null) ( return User.Sähköposti; ) //muuten anonyymi return "anonyymi"; ) ) public void Init(merkkijono sähköposti, IRepository arkisto) ( if (!string.IsNullOrEmpty(sähköposti)) ( User = repository.GetUser(sähköposti);
Lisää uusi IRepositoryyn Hanki menetelmä Käyttäjä (sähköposti). Toteutus kohteelle SqlRepository.GetUser() (LessonProject.Model:/SqlRepository/User.cs):
julkinen IAuthentication Auth ( get; set; ) public User CurrentUser ( get ( return ((UserIndentity)Auth.CurrentUser.Identity).User; ) )
julkinen käyttöliittymä IUserProvider ( User User ( get; set; ) ) ... julkinen luokka UserIndentity: IIdentity, IUserProvider ( ///
Yritetään nyt alustaa kaikki.
Lisätään ensin IAuthentication + Custom Authentication Ninject-rekisteröintiin (/App_Start/NinjectWebCommon.cs):
public class AuthHttpModule: IHttpModule ( public void Alku app.Context; var auth = DependencyResolver.Current.GetService
Yhdistämme moduulin Web.configissa:
_Layout.cshtml (/Areas/Default/Views/Shared/_Layout.cshtml):
UserLogin.cshtml (/Areas/Default/Views/Home/UserLogin.cshtml):
@model LessonProject.Model.User @if (Model != null) (
LoginController Kirjautumis-/lähtöohjain (/Areas/Default/Controllers/LoginController.cs):
Julkinen luokka LoginController: DefaultController ( public ActionResult Index() ( return View(new LoginView()); ) public ActionResult Index(LoginView loginView) ( if (ModelState.IsValid) ( var user = Auth.Login(loginView.Email, loginView. Salasana, loginView.IsPersistent); if (käyttäjä != null) ( return RedirectToAction("Index", "Home"); ) ModelState["Salasana"].Errors.Add("Salasanat eivät täsmää" ) return View( loginView) ); ) public ActionResult Logout() ( Auth.LogOut(); return RedirectToAction("Hakemisto", "Etusivu"); ) )
LoginView.cs (/Models/ViewModels/LoginView.cs):
public class LoginView ( julkinen merkkijono Sähköposti ( get; set; ) public string Salasana ( get; set; ) public bool IsPersistent ( get; set; ) )
Kirjautumissivu Index.cshtml (/Areas/Default/Views/Index.cshtml):
@model LessonProject.Models.ViewModels.LoginView @( ViewBag.Title = "Login"; Layout = "~/Areas/Default/Views/Shared/_Layout.cshtml"; } !}
Sisäänkäynti
@using (Html.BeginForm("Index", "Login", FormMethod.Post, new ( @class = "form-horizontal" ))) ( }Ajetaan ja tarkistetaan:
Kaikki lähteet sijaitsevat osoitteessa
Viimeksi päivitetty: 31.10.2015
ASP.NET MVC 5:n julkaisua leimasi uusi valtuutus- ja todennusjärjestelmä .NET-sovelluksissa nimeltä ASP.NET Identity. Tämä järjestelmä korvaa ASP.NET MVC 4:ssä käyttöönotetut Simple Membership -palveluntarjoajat.
Napsauttamalla Muuta todennusta -painiketta voimme muuttaa todennustyyppiä valitsemalla jonkin seuraavista:
Ei todennusta: ASP.NET Identity, eikä siinä ole sisäänrakennettua todennusjärjestelmää
Yksittäiset käyttäjätilit: Projekti sisältää oletuksena ASP.NET Identity -järjestelmän, jonka avulla voit valtuuttaa sekä käyttäjiä sovelluksessa että ulkoisten palveluiden, kuten Googlen, Twitterin jne., käytön.
Organisaation tilit: sopii yksittäisten yritysten ja organisaatioiden verkkosivustoille ja verkkosovelluksiin
Windows Authentication: Windows-tilejä käyttävien intranet-verkkojen todennusjärjestelmä
Jätetään oletusarvo, eli yksittäiset käyttäjätilit, ja luodaan projekti.
Luodulla projektilla on jo oletusarvoisesti kaikki valtuutukseen tarvittava infrastruktuuri: mallit, ohjaimet, näkymät. Jos katsomme References-solmua, näemme siellä useita avainkirjastoja, jotka sisältävät valtuutukseen ja todentamiseen tarvittavat luokat:
Nämä ovat useita OWIN-kirjastoja, jotka lisäävät OWIN-toiminnallisuuden projektiin, sekä kolme itse ASP.NET Identity -kirjastoa:
Microsoft.AspNet.Identity.EntityFramework: sisältää Entity Framework -luokkia, jotka käyttävät ASP.NET Identityä ja kommunikoivat SQL Serverin kanssa
Microsoft.AspNet.Identity.Core: Sisältää useita keskeisiä ASP.NET Identity -liittymiä. Näiden rajapintojen käyttöönotto mahdollistaa MS SQL Serverin laajemman käytön ja käyttää muita tietokantajärjestelmiä, mukaan lukien NoSQL-järjestelmiä, tilin tallennustilana.
Microsoft.AspNet.Identity.OWIN: Tuo OWIN-todennuksen ASP.NET MVC -sovellukseen käyttämällä ASP.NET Identityä
Koska kaikki infrastruktuuri on jo projektissa, käynnistetään projekti ja etsitään linkki selaimessa näkyvältä sivulta Rekisteröidy ja napsauta sitä. Syötä avautuvalle rekisteröintisivulle joitain tietoja:
Rekisteröinnin jälkeen kirjautuminen näkyy verkkosovelluksen verkkosivun oikeassa yläkulmassa. Kun rekisteröinti on suoritettu, voimme kirjautua ulos napsauttamalla Kirjaudu ulos ja kirjautua uudelleen sisään. Näin ollen voimme jo alkaa käyttää sisäänrakennettua todennusjärjestelmää ASP.NET MVC 5 -sovelluksessa. Katsotaan nyt sen pääkohtia.
Ensinnäkin missä tämä kaikki on tallennettu? Mihin rekisteröityjen käyttäjien tiedot menevät?
Tässä tapauksessa käytetään Code First -lähestymistapaa. Web.config-tiedostossa on jo oletusyhteysmerkkijono, joka määrittää tietokantahakemiston. Jos laajennamme App_Data-kansiota, voimme nähdä luodun tietokannan:
Jos tietokanta ei yhtäkkiä näy kansiossa, napsauta Solution Explorer -ikkunan yläosassa olevaa Näytä kaikki tiedostot -painiketta.
Voimme avata tämän tietokannan Server Explorer -ikkunassa ja nähdä sen sisällön:
Oletusarvoisesti, kun rekisteröidään ensimmäistä käyttäjää, luodaan seuraavat taulukot:
MigrationHistory: EntityFramework käyttää tietokantojen siirtoja
AspNetRoles: sisältää roolimääritykset
AspNetUserClaims: taulukko, joka tallentaa joukon vaatimuksia. Vaatimus ottaa käyttöön erilaisen valtuutusmallin rooleihin verrattuna. Karkeasti sanottuna vaatimus sisältää joitain tietoja käyttäjästä, esimerkiksi sähköpostiosoitteen, kirjautumistunnuksen, iän jne. Ja näiden tietojen avulla voit tunnistaa käyttäjän ja antaa hänelle asianmukaiset käyttöoikeudet.
AspNetUserLogins: käyttäjien kirjautumistaulukko
AspNetUserRoles: taulukko, joka asettaa tietyt roolit käyttäjille
AspNetUsers: todellinen käyttäjätaulukko. Jos avaamme sen, näemme rekisteröityneen käyttäjän tiedot
AspNet Identityn tärkeimmät objektit ovat käyttäjät ja roolit. UserManager-luokkaan on tallennettu kaikki toiminnot käyttäjien luomiseen, poistamiseen ja vuorovaikutukseen käyttäjäkaupan kanssa. Rooleja ja niiden hallintaa varten AspNet Identity määrittelee RoleManager-luokan. UserManager- ja RoleManager-luokat sijaitsevat Microsoft.AspNet.Identity.Core-kirjastossa.
Jokainen UserManager-käyttäjä edustaa IUser-käyttöliittymäobjektia. Ja kaikki käyttäjien hallintatoiminnot suoritetaan IUserStore-objektin edustaman tallennustilan kautta.
Jokainen rooli edustaa IRole-käyttöliittymän toteutusta, ja RoleManager-luokka hallitsee rooleja IRoleStoren kautta.
Microsoft.AspNet.Identity.EntityFramework-nimiavaruus tarjoaa IUser-, IRole-, IUserStore- ja IRoleStore-rajapintojen suoran toteutuksen:
IdentityUser-luokka on IUser-liittymän toteutus. Ja käyttäjäkauppaluokka - UserStore - toteuttaa IUserStore-rajapinnan.
Vastaavasti IdentityRole-luokka toteuttaa IRole-rajapinnan ja roolivarastoluokka RoleStore toteuttaa IRoleStore-rajapinnan.
Ja tietokannan kanssa vuorovaikutusta varten IdentityDbContext-kontekstiluokka määritellään Microsoft.AspNet.Identity.EntityFramework-nimiavaruudessa.
ASP.NET MVC -sovelluksessa emme työskentele suoraan IdentityUser- ja IdentityDbContext-luokkien kanssa. Oletusarvoisesti tiedosto lisätään projektiin Mallit-kansiossa IdentityModels.cs, joka sisältää käyttäjäluokkien ja datakontekstin määritelmät:
Julkinen luokka ApplicationUser: IdentityUser ( julkinen asynkronointitehtävä
Sovelluksessa emme työskentele suoraan IdentityUser- ja IdentityDbContext-luokkien kanssa, vaan käsittelemme jälkeläisluokkia.
ApplicationUser-luokka perii kaikki ominaisuudet IdentityUserilta. Se lisää myös GenerateUserIdentityAsync()-menetelmän, joka luo ClaimsIdentity-objektin kutsumalla UserManager.CreateIdentityAsync. Tämä objekti sisältää tietoja tästä käyttäjästä.
Tämän arkkitehtuurin avulla voit ottaa valmiita toimintoja ja tarvittaessa lisätä uusia, esimerkiksi lisätä käyttäjälle uuden ominaisuuden tai lisätä uuden taulukon tietokantaan.
En kuvaile yksityiskohtaisesti kaikkia AspNet Identityn toimintoja, jotka on lisätty projektiin oletuksena. Esitän lyhyesti vain tärkeimmät ominaisuudet.
Ensinnäkin, jotta AspNet Identity otetaan käyttöön, kaksi tiedostoa lisätään projektiin App_Start-kansiossa. Tiedosto Startup.Auth.cs sisältää OWIN-sovellusten käynnistysluokan. Koska AspNet Identity käyttää OWIN-infrastruktuuria, tämä luokka on yksi tärkeimmistä ja tarpeellisista työhön.
Tiedosto IdentityConfig.cs sisältää useita lisäapuluokkia: palvelut kaksivaiheiseen validointiin sähköpostitse ja puhelimitse EmailService ja SmsService , käyttäjähallintaluokka ApplicationUserManager , joka lisää useita lisätoimintoja UserManageriin, ja ApplicationSignInManager-luokka, jota käytetään sisään- ja uloskirjautumiseen. sivustosta.
Todennus- ja tilinhallintajärjestelmän ydintoiminnot sijaitsevat kahdessa ohjaimessa: AccountController ja ManageController
AccountController määrittelee menetelmät kirjautumiseen, rekisteröintiin, sähköpostilla tai tekstiviestillä lähetetyn koodin varmentamiseen, salasanan palautukseen, salasanan muistutukseen, sisäänkirjautumiseen ulkoisten palveluiden avulla. ManageController-ohjainta käytetään tilin hallintaan, ja se tarjoaa mahdollisuuden vaihtaa salasanaa ja hallita puhelinnumeroita järjestelmässä. Molemmille ohjaimille kaikki tarvittavat näkymät ja erikoisnäkymämallit luodaan oletusarvoisesti.
Huolimatta siitä, että oletuksena meillä on jo valmiita toimintoja, joissakin tapauksissa, esimerkiksi tekstiviestien tai sähköpostin lähettämiseksi, tarvitaan lisämäärityksiä. Katsotaanpa nyt AspNet Identity -järjestelmän pääkohtia.
Oletko luonut WebAPI:n ja haluat nyt hallita sen käyttöä? Tässä artikkelisarjassa tarkastelemme useita vaihtoehtoja WebAPI:n suojaamiseksi luvattomilta käyttäjiltä. Sarja kattaa molemmat puolet, käyttäjien todennuksen ja valtuutuksen.
- Todennus - mahdollistaa käyttäjän yksilöllisen tunnistamisen. Esimerkiksi Alice kirjautuu sisään käyttäjätunnuksellaan ja salasanallaan, ja palvelin käyttää näitä tietoja Alicen todentamiseen.
- Valtuutus päättää, voiko käyttäjä suorittaa tiettyjä toimintoja. Liisalla on esimerkiksi saattanut olla lukuoikeus resurssiin, mutta hän ei voi luoda uutta resurssia.
Ensimmäinen artikkelisarja tarjoaa yleiskatsauksen ASP.NET Web API:n todennukseen ja valtuutukseen. Muissa artikkeleissa kuvataan yleisiä WebAPI-todennusskenaarioita.
Todennus
WebAPI olettaa, että todennuksen suorittaa isäntä, jossa se sijaitsee. Web-isännöinnissä isäntä on IIS, joka käyttää todentamiseen HTTP-moduuleja. Voit määrittää projektisi käyttämään IIS:n tai ASP.NETin sisäänrakennettuja todennusmoduuleja tai kirjoittaa oman HTTP-moduulin mukautetun todennuksen suorittamiseksi.
Kun isäntä todentaa käyttäjän, se luo IPprincipal-objektin, joka edustaa suojauskontekstia, jossa koodi suoritetaan. Luotu objekti on liitetty nykyiseen säikeeseen ja sitä voidaan käyttää Thread.CurrentPrincipal-ominaisuuden kautta. Suojauskonteksti sisältää liitetyn Identity-objektin, joka sisältää tietoja käyttäjästä. Jos käyttäjä on todennettu, Identity.IsAuthenticated-ominaisuus palauttaa tosi. Nimettömistä pyynnöistä omaisuus palauttaa vääriä.
HTTP-viestinkäsittelijöiden käyttäminen todentamiseen.
Isännän sijaan todennuslogiikka voidaan sijoittaa HTTP-viestinkäsittelijään. Tässä tapauksessa sanomankäsittelijä tutkii HTTP-pyynnön ja asettaa itse suojauskontekstin.
Muutamia esimerkkejä siitä, miksi todennus saattaa olla tarpeen viestinkäsittelijöissä:
- HTTP-moduuli näkee kaikki ASP.NET-kanavan kautta kulkevat pyynnöt, käsittelijä näkee vain WebAPI:n tarkoitetut pyynnöt
- Voit asentaa kullekin reitille erilliset viestikäsittelijät käyttämällä erilaisia todennusmenetelmiä
- HTTP-moduulit ovat IIS-kohtaisia. Viestinkäsittelijät ovat isännästä riippumattomia, ja niitä voidaan käyttää sekä web-isännöinnissä että itseisännöinnissa.
- HTTP-moduulit ovat mukana IIS:n kirjaamisessa, auditoinnissa jne.
- HTTP-moduulit käynnistetään aiemmin pyyntöketjussa. Jos todennat viestin käsittelijälle, suojauskontekstia ei luoda ennen kuin käsittelijä on suoritettu. Lisäksi suojauskonteksti palaa edelliseen tilaan, kun vastaus pyyntöön lähtee sanomankäsittelijästä.
Yleensä, jos et aio käyttää itsepalvelua, HTTP-todennusmoduulien käyttö on paras vaihtoehto. Muussa tapauksessa logiikka tulisi siirtää viestinkäsittelijöihin.
Suojauskontekstin asettaminen
Jos sovelluksesi suorittaa todentamiseen liittyvää logiikkaa, sinun on asetettava suojauskonteksti kahdessa ominaisuudessa:
- Thread.CurrentPrincipal on tavallinen tapa asettaa suojauskonteksti säikeelle .NET:ssä
- HttpContext.Current.User - ASP.NET-kohtainen ominaisuus
Seuraava koodi näyttää kuinka suojauskonteksti asetetaan:
Yksityinen void SetPrincipal(IPprincipal Principal) ( Thread.CurrentPrincipal = päämies; if (HttpContext.Current != null) ( HttpContext.Current.User = päämies; ) )
Verkkopalvelua varten sinun on asetettava suojauskonteksti molemmissa ominaisuuksissa, muuten suojauskonteksti voi muuttua epäjohdonmukaiseksi. Varmistaaksesi, että koodisi on riippumaton isännöintimenetelmästä, sinun tulee tarkistaa HttpContext.Current-ominaisuuden null-arvo koodin osoittamalla tavalla. Itseisännöinnin tapauksessa sen arvo on nolla, eikä suojauskontekstin asettamista vaadita.
Valtuutus
- Valtuutussuodattimet käsitellään ennen ohjainmenetelmiä. Jos pyyntöä ei ole valtuutettu, suodatin palauttaa virheilmoituksen eikä ohjainmenetelmää kutsuta.
- Ohjainmenetelmässä saat nykyisen suojauskontekstin ApiController.User-ominaisuudesta. Voit esimerkiksi suodattaa resurssiluettelon käyttäjänimen perusteella ja palauttaa vain kyseisen käyttäjän käytettävissä olevat resurssit.
Attribuutin käyttäminen
WebAPI tarjoaa sisäänrakennetun valtuutussuodattimen, AuthorizeAttribute, joka tarkistaa, onko käyttäjä valtuutettu. Jos ei, suodatin palauttaa koodin HTTP-tilat 401 (Ei valtuutettu), kutsumatta menetelmää.
Voit käyttää suodatinta maailmanlaajuisesti, ohjaintasolla tai menetelmätasolla.
Suodata globaalilla tasolla: Rajoita pääsyä WebAPI-ohjaimen mukaan lisäämällä AuthorizeAttribute-suodatin yleiseen suodatinluetteloon:
Julkinen staattinen void Register(HttpConfiguration config) ( config.Filters.Add(new AuthorizeAttribute()); )
Säätimen tasosuodatin: Jos haluat rajoittaa pääsyä tiettyyn ohjaimeen, lisää suodatin ohjainluokan attribuutiksi:
// Vaadi valtuutus kaikkiin ohjaimen toimiin. public class ValuesController: ApiController ( julkinen HttpResponseMessage Get(int id) ( ... ) public HttpResponseMessage Post() ( ... ) )
Menetelmän tason suodatin: Jos haluat rajoittaa menetelmän käyttöä, lisää siihen attribuutti:
Julkinen luokka ValuesController: ApiController ( public HttpResponseMessage Get() ( ... ) // Vaadi valtuutus tiettyyn toimintoon. public HttpResponseMessage Post() ( ... ) )
Lisäksi voit asettaa rajoituksen ohjaimelle ja sallia anonyymin pääsyn yksittäisiin menetelmiin määritteen avulla. Seuraavassa esimerkissä pääsy kohteeseen Postitusmenetelmä rajoitettu, ja Get-menetelmä on käytettävissä nimettömille puheluille:
Julkinen luokka ValuesController: ApiController ( julkinen HttpResponseMessage Get() ( ... ) public HttpResponseMessage Post() ( ... ) )
Aiemmissa esimerkeissä suodatin salli pääsyn kaikille todennetuille käyttäjille, mutta esti pääsyn vain anonyymeiltä käyttäjiltä. Voit myös myöntää käyttöoikeuden tietyt käyttäjät tai roolit:
// Rajoita käyttäjän mukaan: public class ValuesController: ApiController ( ) // Rajoita roolin mukaan: public class ValuesController: ApiController ( )
WebAPI-ohjainten AuthorizeAttribute-suodatin on System.Web.Http-nimiavaruudessa. System.Web.Mvc-nimiavaruudessa on samanlainen suodatin MVC-ohjaimille. Tämä tyyppi ei ole yhteensopiva WebAPI-ohjainten kanssa.
Mukautettu valtuutussuodatin
Muokatun suodattimen on perittävä jokin seuraavista tyypeistä:
- AuthorizeAttribute. Peri tämä luokka toteuttaaksesi synkronisen valtuutuslogiikan nykyisen käyttäjän tai käyttäjän roolin perusteella.
- AuthorizationFilterAttribute. Tämä luokka hyödyllinen valtuutuslogiikan toteuttamisessa, joka ei välttämättä perustu käyttäjään tai hänen rooliinsa.
- IAuthorizationFilter. Toteuta tämä käyttöliittymä asynkroniselle valtuutuslogiikalle. Valtuutus sisältää esimerkiksi asynkronisia tai verkkopuheluita (jos logiikka perustuu prosessorin laskelmiin, on parempi periä AuthorizationFilterAttribute, jotta ei kirjoiteta asynkronisia menetelmiä)
Seuraava kaavio näyttää suodatinluokkahierarkian:
Valtuutus ohjainmenetelmän sisällä
Joissakin tapauksissa voit antaa pyynnön jatkaa, mutta muuttaa käyttäytymistä suojauskontekstin perusteella. Esimerkiksi kyselyn tulos riippuu käyttäjän roolista. Ohjainmenetelmän sisällä voit saada nykyisen suojauskontekstin käyttämällä ApiController.User-ominaisuutta:
Julkinen HttpResponseMessage Get() ( if (User.IsInRole("Järjestelmänvalvojat")) ( // ... ) )
* Käännös on tehty vapaalla tyylillä, ehkä jotkut loukkaantuvat anglicismeista, kuten "custom", mutta näistä sanoista on tullut osa sen ammattikieltä, eikä venäjänkielistä käännöstä oteta niin kuin sen pitäisi.
