Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web development, networking and server security. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Jasig - CAS Protokol

CAS Protokol

1. Uvod

Ovo je zvanična specifikacija za CAS 1.0 i 2.0 protokole. Podležno je promenama.

1.1. Sporazumi i definicije

Ključne reči "MORA", "NE SME", "ZAHTEVA", "BIĆE", "NEĆE BITI", "TREBA", "NE TREBA", "PREPORUČENO", "MOŽE" i "OPCIONO" u ovom dokumentu treba tumačiti kao što je opisano u RFC 2119[1].

  • "Klijent" se odnosi na krajnjeg korisnika i/ili web pretraživača.
  • "Server" se odnosi na Central Authentication Service server.
  • "Usluga" se odnosi na aplikaciju kojoj klijent pokušava da pristupi.
  • "Sekundarna usluga" odnosi se na aplikaciju kojoj usluga pokušava da pristupi u ime klijenta. To se može nazivati i "ciljanom uslugom".
  • <LF> je umetak od jednog reda (ASCII vrtednost 0x0a).

2. CAS URI-i

CAS predstavlja protokol baziran na HTTP[2,3]- koji zahteva da svaka od njegovih komponenti bude pristupacna kroz odredeni URI. U ovom odeljku govorice se o svakom od URI-a.

2.1. /prijava (login) kao akreditivni zahtevalac

/prijava URI radi sa dva načina ponašanja: kao akreditivni zahtevalac i kao akreditivni prihvatilac. Odgovara na akreditive tako što nastupa kao akreditivni prihvatilac, inače nastupa kao akreditivni zahtevalac.

Ako je klijent već uspostavio jedinstvenu upisnu sesiju sa CAS, web pretraživač predstavlja CAS-u sigurnosni kolačić koji sadrži niz koji identifikuje kartu za dodelu karata. Kolačić se naziva kolačićem za dodelu karata. Ako kolačić za dodelu karata cilja na validnu kartu za dodelu karata, CAS može izdati servisnu kartu, pod uslovom da se ispune svi ostali uslovi iz ove specifikacije. Vidi Odeljak 3.6 za više informacija o kolačićima za dodelu karata

2.1.1. parametri

Sledeci parametri HTTP zahteva se mogu preneti na /login za vreme njegovog nastupa kao akreditivnog zahtevaoca. Svi su osetljivi na velika i mala slova i svima se MORA rukovati preko /prijave.

  • usluga [OPCIONO] - identifikator aplikacije kojoj klijent pokušava da pristupi. U skoro svim slučajevima to će biti URL aplikacije. Obratite pažnju da kao parametar HTTP zahteva, ova URL vrednosti MORA biti URL-kodirana kao što je opisano u Odeljku 2.2 od RFC 1738[4]. Ako usluga nije određena i jedinstvena upisna sesija još uvek ne postoji, CAS TREBA da zahteva akreditive od korisnika kako bi otpočeo jedinstvenu upisnu sesiju. Ako usluga nije određena, a jedinstvena upisna
  • obnova [OPCIONO] - ako je ovaj parametar podešen, jedinstveni upis će se preći. U tom slučaju CAS će zahtevati od kiljenta da pezentuje akreditaciju bez obzira na postojanje jedinstvene upisne sesije uz CAS. Ovaj parametar nije kompatibilan sa parametrom "mrežnog prolaza". Usluga koja preusmerava na /prijavu URI i logovanje formira prikaze u /prijavi, a URI NE TREBA da podešava i zahtevane parametre "obnove" i "mrežnog prolaza". Ponašanje nije definisano ako je podešeno i jedno i drugo. PREPORUČUJE SE da CAS realizacija ignoriše parametar "mrežnog prolaza" ako je "obnova" podešena. PREPORUČUJE SE da, kada se podesi parametar obnove, njegova vrednost bude “istinito”.
  • mrežni prolaz [OPCIONO] - ako je ovaj parametar podešen, CAS neće tražiti akreditaciju od klijenta. Ako klijent ima prethodno postojeću jedinstvenu upisnu sesiju u CAS ili ako se jedinstvena upisna sesija može uspostaviti ne-interaktivnim sredstvima (tj. poverilačkom autentifikacijom), CAS MOŽE preusmeriti klijenta na URL koji odredi parametar “servisa”, dodavajući validnu kartu usluge. (CAS takođe MOŽE umetnuti stranicu za savet koja će klijenta informisati da se desila CAS autentifikacija). Ako klijent nema jedinstvenu upisnu sesiju uz CAS i ne-interaktivna autentifikacije ne može da se uspostavi, CAS MORA preusmeriti klijenta na URL koji odredi parametar “servisa”, bez parametra “karte” prikačenog na URL. Ako parametar “servisa” nije određen, a “mrežni prolaz” je podešen, ponašanje CAS-a nije definisano. PREPORUČUJE SE da au tom slučaju CAS zahteva akreditaciju kao što bi radio kada nijedan parametar ne bi bio određen. Ovaj parametar nije kompatibilan sa parametrom “obnove”. Ponašanje nije definisano ako su oba podešena. PREPORUČUJE SE da kada je mrežni prolaz podešen, da njegova vrednost bude “istinito”.

2.1.2. URL primeri za /prijavu

Jednostavan primer za prijavljivanje:

https://server/cas/login?service=http%3A%2F%2Fwww.service.com

Ne zahtevaj se na korisnik/lozinka:

https://server/cas/login?service=http%3A%2F%2Fwww.service.com&gateway=true

Uvek zahtevaj na korisnik/lozinka:

https://server/cas/login?service=http%3A%2F%2Fwww.service.com&renew=true

2.1.3. odgovor na korisnik/lozinka autentifikaciju

Kada se /prijava ponaša kao akreditivni zahtevalac, odgovor će varirati zavisno od vrste akreditacije koja se zahteva. U većini slučajeva, CAS će odgovoriti tako što će prikazati ekran za prijavljivanje koji zahteva korisničko ime i lozinku. Ta stranica MORA uključiti formu s parametrima, “korisničko ime”, “lozinku” i “It”. Forma takođe MOŽE uključiti parametar “upozorenja”. Ako se odredi “servis” za /prijavu, “usluga” takođe MORA biti parametar forme i sadržati vrednost koja je originalno bila preneta na /prijavu. O ovim parametrima se detaljno govori u Odeljku 2.2.1. Forma se MORA preneti kroz HTTP POST metod na /prijavu koja će tada nastupiti kao akreditivni prihvatilac, o čemu se govori u Odeljku 2.2.

2.1.4. odgovor za poverilacku autentifikaciju

Poverilacka autentifikacija se prilagodava obzirima proizvoljnih aspekata zahteva kao osnovama za autentifikaciju. Odgovarajuce korisnicko iskustvo za poverilacku autentifikaciju treba biti vrlo jasno odredeno u okvirima lokalne politike i logistike odredenog realizovanog mehanizma autentifikacije.

Kada se /prijava ponaša kao akreditivni zahtevalac za poverilačku autentifikaciju, njeno ponašanje će biti određeno vrstom akreditacije koju će primiti. Ako su akreditacije validne, CAS MOŽE transparentno preusmeriti korisnika na uslugu. Alternativno, CAS MOŽE prikazati upozorenje da su akreditacije već prezentovane i omogućiti klijentu da potvrdi da li želi da ih upotrebi. PREPORUČUJE SE da CAS realizacija omogući raspoređivaču da izabere željeno ponašanje. Ako akreditacije nisu validne ili ako ne postoje, PREPORUČUJE SE da CAS prikaže klijentu razlog zbog kojeg je autentifikacija propala i da predstavi korisniku alternativna sredstva autentifikacije (npr. autentifikaciju korisničko ime/lozinka).

2.1.5. odgovor za jedinstvenu upisnu autentifikaciju

Ako je klijent već uspostavio jedinstvenu upisnu sesiju za CAS, klijentov kolačić HTTP sesije će se predstaviti /prijavi, a ponašanjem će se upravljati kao što je opisano u Odeljku 2.2.4. Ipak, ako je parametar “obnove” podešen, ponašanjem će se rukovati kao u Odeljku 2.1.3 ili 2.1.4.

2.2. /prijava upis kao akreditivni prihvatilac

Kada se skup prihvaćenih akreditacija prenese na /prijavu, /prijava nastupa kao akreditivni prihvatilac, a njeno ponašanje je definisano u ovom odeljku.

2.2.1. parametri koji su zajednicki za sve vrste autentifikacija

Sledeci parametri HTTP zahteva se MOGU preneti na /prijavu za vreme njenog nastupa kao akreditivnog prihvatioca. Oni su svi osetljivi na velika i mala slova i svima njima MORA upravljati /prijava.

  • usluga [OPCIONO] - URL aplikacije kojoj klijent pokušava da pristupi. CAS MORA da preusmeri klijenta na taj URL posle uspešne autentifikacije. O tome se detaljno govori u Odeljku 2.2.4.
  • upozorenje [OPCIONO] - ako je ovaj parametar podešen, jedinstveni upis NE SME biti transparentan. Klijent se MORA odazvati pre autentifikacije za drugu uslugu.

2.2.2. parametri za autentifikaciju korisnickog imena/lozinke

Kao dodatak OPCIONIM parametrima opisanim u Odeljku 2.2.1, sledeci parametri HTTP zahteva se MORAJU preneti na /prijavu za vreme njenog nastupa kao akreditivnog prihvatioca za autentifikaciju korisnickog imena/lozinke. Svi su osetljivi na velika i mala slova.

  • korisničko ime [ZAHTEVANO] - korisničko ime klijenta koji pokušava da se prijavu
  • lozinka [ZAHTEVANO] - lozinka klijenta koji pokušava da se prijavu
  • To [ZAHTEVANO] - karta za prijavljivanje. To se pruža kao deo forme za prijavljivanje o cemu se govori u Odeljku 2.1.3. O samoj karti za prijavljivanje govori se u Odeljku 3.5.

2.2.3. parametri za poverilacku autentifikaciju

Ne postoje ZAHTEVANI parametri HTTP zahteva za poverilacku autentifikaciju. Poverilacka autentifikacija se može bazirati na bilo kom aspektu HTTP zahteva.

2.2.4. odgovor

Jedan od sledecih odgovora MORA da bude dat od strane /prijave kada ona operiše kao akreditivni prihvatilac.

  • uspešno prijavljivanje: preusmerava klijenta na URL koji odredi parametar “servisa” na način koji neće uzrokovati da se klijentove akreditacije proslede na servis. To preusmerenje MORA da rezultira time što će klijent izdati zahtev za DOBIJANJE kao servisu (GET zahtev). Zahtev MORA uključiti validnu servisnu kartu koja se prenosi kao parametar HTTP zahteva, “karta”. Vidi dodatak B za više informacija. Ako “servis” nije određen, CAS MORA prikazati poruku koja obaveštava klijenta da je uspešno otpočeo jedinstvenu upisnu sesiju.
  • neuspešno prijavljivanje: vraća na /prijavu kao na akreditivnog zahtevaoca. PREPORUČUJE SE u tom slučaju da CAS server prikaže klijentu poruku o grešci sa opisom razloga neuspeha (npr. pogrešna lozinka, zaključan nalog itd.) i ako je moguće, da pruži klijentu priliku da pokuša ponovo da se prijavi.

2.3. /odjava (logout)

/odjava poništava klijentovu jedinstvenu upisnu CAS sesiju. Kolačić za dodelu karata (Odeljak 3.6) se poništava i naredni zahtev za prijavljivanje neće dobiti servisne karte sve dok korisnik ne prezentuje prvenstvene akreditacije (i time uspostavi novu jedinstvenu upisnu sesiju).

2.3.1. parametri

Sledeći parametar HTTP zahteva MOŽE biti određen za /odjavu. Osetljiv je na velika i mala slova i njime TREBA da upravlja /odjava.

  • url [OPCIONO] - ako je "url" određen, URL kojeg oredi "url" TREBA da bude na stranici odjavljivanja sa opisnim tekstom. Na primer: "Aplikacija iz koje ste se upravo odjavili obezbedila je link koji bi želela da pratite. Molimo vas kliknite ovde za pristup na http://www.go-back.edu."

2.3.2. odgovor

/odjava MORA da prikaže stranicu koja izjavljuje da se korisnik odjavio. Ako je realizovan "url" parametar zahteva, /odjava TREBA takođe da pruži link ka datom URL-u kao što je opisano u Odeljku 2.3.1.

2.4. /potvrda [CAS 1.0] (validate)

/potvrda proverava validnost servisne karte. /potvrda je deo CAS 1.0 protokola i stoga ne upravlja posredničkim autentifikacijama. CAS MORA odgovoriti neuspešnim odgovorom na potvrdu karte kada se posrednička karta prenese na /potvrdu.

2.4.1. parametri

Sledeci parametri HTTP zahteva MOGU biti odredeni za /potvrdu. Osetljivi su na velika i mala slova i svima MORA upravljati /potvrda.

  • usluga [ZAHTEVANO] - identifikator usluge za koju se dodeljuje karta, kao što je opisano u Odeljku 2.2.1.
  • karta [ZAHTEVANO] - servisna karta koju izdaje /prijava. Servisne karte su opisane u Odeljku 3.1.
  • obnova [OPCIONO] - ako je ovaj parametar podešen, potvrda karte ce uspeti jedino ako se servisna karta izda iz prezentacije korisnickih prvenstvenih akreditacija. Bice neuspešno ako se karta izda iz jedinstvene upisne sesije.

2.4.2. odgovor

/potvrda ce vratiti jedan od sledeca dva odgovora:

O uspešnoj potvrdi karte:

yes<LF>
username<LF>

O neuspešnoj potvrdi karte:

no<LF>
<LF>

2.4.3. URL primeri za /potvrdu

Jednostavan pokušaj potvrde:

https://server/cas/validate?service=http%3A%2F%2Fwww.service.com&ticket=...

Osiguranje da je servisnu kartu izdala prezentacija prevenstvenih akreditacija:

https://server/cas/validate?service=http%3A%2F%2Fwww.service.com&ticket=...

2.5. /servisPotvrda [CAS 2.0] (serviceValidate)

/servisPotvrda proverava validnost servisne karte i vraća odgovor kao XML-fragment. /servisPotvrda takođe MORA da generiše i izda kartu koja dodeljuje posrednika kada se to zahteva. /servisPotvrda NE SME da vrati uspešnu autentifikaciju ako primi posrednički kartu. PREPORUČUJE SE da, ako /servisPotvrda primi posredničku kartu, poruka o grešci u XML odgovoru TREBA da objasni da je potvrda bila neuspešna zato što je posrednička karta bila preneta na /servisPotvrdu.

2.5.1. parametri

Sledeći parametri HTTP zahteva MOGU biti određeni za /servisPotvrdu. Osetljivi su na velika i mala slova i svima MORA upravljati /servisPotvrda.

  • servis [ZAHTEVANO] - identifikator usluge za koju se karta izdaje, kao što je opisano u Odeljku 2.2.1.
  • karta [ZAHTEVANO] - servisna karta koju izdaje /prijava. Servisne karte opisane su u Odeljku 3.1.
  • pgtUrl [OPCIONO] - URL posredničkog povratnog poziva. O tome je pisano u Odeljku 2.5.4.
  • obnova [OPCIONO] - ako je ovaj parametar podešen, potvrda karte će uspeti samo ako je servisna karta izdata iz prezentacije korisnikovih prvenstvenih akreditacija. Biće neuspešna ako se karta izda iz jedinstvene upisne sesije.

2.5.2. odgovor

/servisPotvrda će vratiti XML formatiran CAS servisOdgovor kao što je opisano u XML šemi u Dodatku A. U nastavku su dati primeri odgovora:

O uspešnoj potvrdi karte:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationSuccess>
        <cas:user>username</cas:user>
            <cas:proxyGrantingTicket>PGTIOU-84678-8a9d...
        </cas:proxyGrantingTicket>
    </cas:authenticationSuccess>
</cas:serviceResponse>

O neuspešnoj potvrdi karte:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationFailure code="INVALID_TICKET">
        Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized
    </cas:authenticationFailure>
</cas:serviceResponse>

2.5.3. kodovi greške

Sledeće vrednosti se MOGU upotrebiti kao atribut “koda” za odgovor o neuspehu autentifikacije. Sledeće je minimalni skup kodova grešaka koje svi CAS serveri MORAJU da realizuju. Realizacija MOŽE uključiti i ostale.

  • INVALIDNI_ZAHTEV - nisu predstavljeni svi zahtevani parametri
  • INVALIDNA_KARTA - podneta karta nije validna ili karta nije došla iz početnog logovanja, a “obnova” je podešena na potvrdu. Telo bloka XML odgovora TREBA da opiše tačne detalje.
  • INVALIDNI_SERVIS - podneta karta je validna, ali naznačena usluga se ne podudara sa uslugom na koju se odnosi karta. CAS MORA da poništi kartu i da onemogući buduće potvrde te karte.
  • INTERNA_GREŠKA - interna greška se dogodila tokom potvrđivanja karte

Za sve kodove grešaka, PREPORUČUJE SE da CAS pruži detaljniju poruku kao telo bloka XML odgovora.

2.5.4. povratni poziv posrednika

Ako servis želi da zastupa klijentovu autentifikaciju ka pozadinskom servisu, mora da dobije kartu koja odobrava posredovanje. Dobijanje te karte se vrši preko posredničkog povratnog URL poziva. Ovaj URL će jednako i sigurno identifikovati pozadinski servis koji posreduje u klijentovoj autentifikaciji. Pozadinski servis tada može odlučiti da li da prihvati akreditacije na osnovu identifikacije povratnog URL poziva od strane pozadinskog servisa.

Mehanizam povratnog poziva posrednika radi na sledeći način:

  1. Servis koji zahteva kartu za dodelu posrednika naznačava, nakon početne servisne karte ili posredničke karte za potvrdu, parametar HTTP zahteva "pgtUrl" za /servisPotvrdu (ili /posrednikaPotvrdu). To je URL povratnog poziva servisa na koji će se CAS povezati da bi potvrdio identitet servisa. Ovaj URL MORA biti HTTPS, a CAS MORA potvrditi i da je SSL sertifikat validan i da se njegovo ime podudara sa imenom servisa. Ako sertifikat ne prođe to potvrđivanje, neće doći do izdavanja karte za dodelu posrednika, a odgovor CAS servisa, opisan u Odeljku 2.5.2 NE SME sadržati blok karte za dodelu posrednika ( block). Tada se izdavanje karte za dodelu posrednika zaustavlja, ali će se potvrđivanje servisne karte nastaviti, vraćajući rezultat o uspehu ili neuspehu. Ako potvrđivanje sertifikata bude uspešno, izdavanje karte za dodelu posrednika se nastavlja kao što je opisano u koraku 2.
  2. CAS koristi HTTP GET zahtev da bi preneo parametre HTTP zahteva "pgtId" i "pgtIou" na pgtUrl. O tome se govori detaljnije u Odeljcima 3.3 i 3.4.
  3. Ako HTTP GET vraća HTTP statusni kod od 200 (OK), CAS MORA odgovoriti na zahtev /servisPotvrde (ili /posrednikPotvrde) odgovorom servisa (Odeljak 2.5.2) koji sadrži kartu za dodelu posrednika IOU (Odeljak 3.4) u okviru bloka. Ako HTTP GET vraća bilo koji drugi statusni kod, izuzimajući HTTP 3xx preusmeravanja, CAS MORA odgovoriti na /servisPotvrda (ili /posrednikPotvrda) zahtev odgovorom servisa koji NE SME sadržati blok. CAS MOŽE slediti svako HTTP preusmerenje koje izda pgtUrl. Ipak, identifikacioni povratni URL poziv koji nastupa nakon potvrđivanja u posredničkom () bloku MORA biti isti URL koji je originalno bio prenet na /servisPotvrdu (ili /posrednikaPotvrdu) kao "pgtUrl" parametar.
  4. Servis, pošto bude primio kartu za dodelu posrednika IOU u CAS odgovoru, kao i kartu za dodelu posrednika IOU iz posredničkog povratnog poziva, upotrebiće kartu za dodelu posrednika IOU za uzajamno povezivanje sa odgovorom potvrđivanja. Servis će tada upotrebiti kartu za dodelu posrednika za nabavku posredničkih karata, kao što je opisano u Odeljku 2.7.

2.5.5. URL primeri za /servisPotvrdu

Jednostavan pokušaj potvrđivanja:

https://server/cas/serviceValidate?service=http%3A%2F%2Fwww.service.com&...

Uveriti se da je servisna karta izdata uz prezentaciju prvenstvenih akreditacija:

https://server/cas/serviceValidate?service=http%3A%2F%2Fwww.service.com&... ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true

Dodaj u povratni poziv URL za posredovanje:

https://server/cas/serviceValidate?service=http%3A%2F%2Fwww.service.com&...

2.6. /posrednikPotvrda [CAS 2.0]

/posrednikPotvrda MORA izvesti iste zadatke potvrđivanja kao i /servisPotvrda i dodatno potvrditi posredničke karte. /posrednikPotvrda MORA biti sposoban za potvrđivanje i servisnih karata i posredničkih karata.

2.6.1. parametri

/posrednikPotvrda ima iste zahteve za parametrima kao i /servisPotvrda. Vidi Odeljak 2.5.1.

2.6.2. odgovor

/posrednikPotvrda će vratiti XML-formatiran CAS servisniOdgovor kao što je opisano u XML šemi u Dodatku A. U nastavku slede primeri odgovora:

O uspešnom potvrđivanju karte:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationSuccess>
        <cas:user>username</cas:user>
        <cas:proxyGrantingTicket>PGTIOU-84678-8a9d...</cas:proxyGrantingTicket>
        <cas:proxies>
            <cas:proxy>https://proxy2/pgtUrl</cas:proxy>
            <cas:proxy>https://proxy1/pgtUrl</cas:proxy>
        </cas:proxies>
    </cas:authenticationSuccess>
</cas:serviceResponse>

Imajte u vidu da, kada se autentifikacija nastavi kroz višestruke posrednike, red po kojem su posrednici prelaženi MORA se reflektovati u bloku. Poslednji posećeni posrednik MORA biti prvi izlistani posrednik, a svi ostali posrednici MORAJU se spustiti na dole kako se novi posrednici budu dodavali. U navedenom primeru servis koji identifikuje https://proxy1/pgtUrl je prvo posećen, a taj servis je posredovao u atentifikaciji servisa koji identifikuje https://proxy2/pgtUrl.

O neuspešnom potvrđivanju karte:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationFailure code="INVALID_TICKET">
        ticket PT-1856376-1HMgO86Z2ZKeByc5XdYD not recognized
    </cas:authenticationFailure>
</cas:serviceResponse>

2.6.3 URL primeri za /posrednikPotvrda

/posrednikPotvrda prihvata iste parametre kao i /servisPotvrda. Vidi Odeljak 2.5.5 za upotrebne primere, zamenjujući "posrednikPotvrdu" za "servisPotvrdu".

2.7. /posrednik [CAS 2.0]

/posrednik obezbeđuje posredničke karte za servis koji je stekao karte za dodelu posrednika i posredovaće u autentifikaciji ka pozadinskim uslugama.

2.7.1. parametri

Sledeći parametri HTTP zahteva MORAJU biti određeni za /posrednika. Oba su osetljiva na velika i mala slova.

  • pgt [ZAHTEVANO] - karta za odobrenje posrednika koju je stekao servis tokom potvrđivanja servisne ili posredničke karte.
  • ciljaniServis [ZAHTEVANO] - identifikator usluga pozadinskih usluga. Imajte u vidu da nisu sve pozadinske usluge web usluge, tako da ovaj identifikator usluga neće uvek biti URL. Ipak, ovde naznačeni identifikator usluga MORA se podudarati sa “servisnim” parametrima određenim za /posrednikPotvrdu nakon potvrđivanja posredničke karte.

2.7.2. оdgovor

/posrednik će vratiti XML-formatiran CAS servisniOdgovor kao što je opisano u XML šemi u Dodatku A. U nastavku slede primeri odgovora:

O uspehu zahteva:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:proxySuccess>
        <cas:proxyTicket>PT-1856392-b98xZrQN4p90ASrw96c8</cas:proxyTicket>
    </cas:proxySuccess>
</cas:serviceResponse>

O neuspehu zahteva:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:proxyFailure code="INVALID_REQUEST">
        'pgt' and 'targetService' parameters are both required
    </cas:proxyFailure>
</cas:serviceResponse>

2.7.3. kodovi greške

Sledeće vrednosti se MOGU upotrebiti kao atribut “koda” odgovora o neuspehu autentifikacije. Sledeće je najmanji skup kodova greške koje svi CAS serveri MORAJU realizovati.

  • INVALIDNI_ZAHTEV - nisu svi zahtevani parametri predstavljeni
  • LOŠ_PGT - dat pgt nije validan
  • INTERNA_GREŠKA - interna greška koja se dogodila tokom potvrđivanja karte

Za sve kodove greške PREPORUČUJE SE da CAS pruži detaljniju poruku kao telo bloka XML odgovora.

2.7.4. URL primer za /posrednika

Jednostavan posrednički zahtev:

https://server/cas/proxy?targetService=http%3A%2F%2Fwww.service.com&pgt=......

3. CAS entiteti

3.1. servisna karta

Servisna karta je neproziran niz koji koristi klijent kao akreditaciju za dobijanje pristupa servisu. Servisna karta se dobija iz CAS-a pošto klijent prezentuje akreditacije i servisni identifikator za /prijavu, kao što je opisano u Odeljku 2.2.

3.1.1. svojstva servisne karte

  • Servisne karte su validne jedino za servisni identifikator koji je naznačen za /prijavu onda kada su generisane. Servisni identifikator NE TREBA da bude deo servisne karte.
  • Servisne karte MORAJU biti validne samo za jedan pokušaj potvrđivanja. Bilo da je potvrđivanje bilo uspešno ili ne, CAS MORA potom poništiti kartu, uzrokujući da svi budući pokušaji potvrđivanja iste karte budu neuspešni.
  • CAS TREBA da učini da nepotvrđene servisne karte isteknu u razumnom vremenskom periodu, nakon što se izdaju. Ako servis za potvrđivanje prezentuje isteklu servisnu kartu, CAS MORA odgovoriti odgovorom o neuspehu potvrđivanja. PREPORUČUJE SE da odgovor potvrđivanja uključi opisnu poruku koja će objasniti zašto je potvrđivanje bilo neuspešno. PREPORUČUJE SE da vreme u kojem će servisna karta biti validna pre nego što istekne ne bude duže od pet minuta. Lokalna bezbednost i sagledavanje CAS iskorišćenosti MOGU odrediti optimalni životni vek nevažeće servisne karte.
  • Servisne karte MORAJU sadržati adekvatne bezbednosne nasumične podatke tako da se karta ne može pogoditi.
  • Servisne karte MORAJU počinjati karakterima "ST-".
  • Servisi MORAJU biti sposobni da prihvate servisne karte do 32 karaktera u dužini. PREPORUČUJE SE da servisi podržavaju servisne karte i do 256 karaktera u dužini.

3.2. posrednička karta

Posrednička karta je neproziran niz koji koristi servis kao akreditaciju za dobijanje pristupa pozadinskim uslugama u ime klijenta. Posredničke karte se dobijaju iz CAS-a nakon prezentovanja od strane servisa validne karte za odobrenje posrednika (Odeljak 3.3) i servisnog identifikatora za pozadinsku uslugu na koju se povezuje.

3.2.1. svojstva posredničke karte

  • Posredničke karte su validne jedino za servisni identifikator koji je naznačen za /posrednika onda kada su generisane. Servisni identifikator NE TREBA da bude deo posredničke karte.
  • Posredničke karte MORAJU biti validne samo za jedan pokušaj potvrđivanja. Bilo da je potvrđivanje bilo uspešno ili ne, CAS MORA potom poništiti kartu, uzrokujući da svi budući pokušaji potvrđivanja iste karte budu neuspešni.
  • CAS TREBA da učini da nepotvrđene posredničke karte isteknu u razumnom vremenskom periodu, nakon što se izdaju. Ako servis za potvrđivanje prezentuje isteklu posredničku kartu, CAS MORA odgovoriti odgovorom o neuspehu potvrđivanja. PREPORUČUJE SE da odgovor potvrđivanja uključi opisnu poruku koja će objasniti zašto je potvrđivanje bilo neuspešno. PREPORUČUJE SE da vreme u kojem će servisna karta biti validna pre nego što istekne ne bude duže od pet minuta. Lokalna bezbednost i sagledavanje CAS iskorišćenosti MOGU odrediti optimalni životni vek nevažeće servisne karte.
  • Posredničke karte MORAJU sadržati adekvatne bezbednosne nasumične podatke tako da se karta ne može pogoditi.
  • Posredničke karte TREBA DA počinju karakterima "PT-". Posredničke karte MORAJU počinjati ii karakterima "ST-" ili "PT-".
  • Pozdainski servisi MORAJU biti sposobni da prihvate servisne karte do 32 karaktera u dužini. PREPORUČUJE SE da pozadinski servisi podržavaju servisne karte i do 256 karaktera u dužini.

3.3. karta za dodelu posrednika

Karta za dodelu posrednika je neprozirni niz koji koristi servis za dobijanje posredničkih karata radi pristupa pozadinskim servisima u ime klijenta. Karte za dodelu posrednika dobijaju se iz CAS-a nakon potvrđivanja servisne ili posredničke karte. Izdavanje karte za dodelu posrednika u potpunosti je opisano u Odeljku 2.5.4.

3.3.1. svojstva karte za dodelu posrednika

  • Karte za dodelu posrednika MOGU koristiti servisi za dobijanje višestrukih posredničkih karata. Karte za dodelu posrednika nisu karte za jednokratnu upotrebu.
  • Karte za dodelu posrednika MORAJU isteći kada se klijent, u čijoj se autentifikaciji posreduje, odjavi iz CAS-a.
  • Karte za dodelu posrednika MORAJU sadržati adekvatne bezbednosne nasumične podatke tako da se karta ne može pogoditi u razumnom vremenskom periodu preko nasilnih napada.
  • Karte za dodelu posrednika TREBA da počinju karakterima "PGT-".
  • Servisi MORAJU biti sposobni da upravljaju kartama za dodelu posrednika od 64 karaktera u dužini. PREPORUČUJE SE da servisi podržavaju karte za dodelu posrednika do 256 karaktera u dužini.

3.4. karte za dodelu posrednika IOU

Karta za dodelu posrednika IOU je neprozirni niz koji se stavlja u odgovor koji daje /servisPotvrda i /posrednikPotvrda i koji je uzajamno povezivao servisnu ili posredničku kartu sa određenom kartom za dodelu posrednika. Vidi Odeljak 2.5.4 za detaljan opis ovog procesa.

3.4.1. svojstva karte za dodelu posrednika IOU

  • Karte za dodelu posrednika IOUi NE TREBA da sadrže nikakvu referencu ka njihovim pridruženim kartama za dodelu posrednika. S obzirom da određeni PGTIOU, NE SME biti moguće izvođenje njihovog odgovarajućeg PGT-a kroz metode algoritama u razumnom vremenskom periodu.
  • Karte za dodelu posrednika IOUi MORAJU sadržati adekvatne bezbednosne nasumične podatke tako da se karta ne može pogoditi u razumnom vremenskom periodu preko nasilnih napada.
  • Karte za dodelu posrednika IOUi TREBA da počinju karakterima "PGTIOU-".
  • Servisi MORAJU biti sposobni da upravljaju PGTIOU-ima od 64 karaktera u dužini. PREPORUČUJE SE da servisi podržavaju PGTIOU-e do 256 karaktera u dužini.

3.5. prijavna karta

Prijavna karta je niz koji je obezbeđen od strane /prijave kao akreditivni zahtevalac i koji je prenet na /prijavu kao akreditivni prihvatilac za autentifikaciju korisničkog imena/lozinke. Njegova svrha je da spreči ponovno pojavljivanje akreditacija usled grešaka u web pretraživačima.

3.5.1. svojstva prijavne karte

  • Prijavne karte koje izdaje /prijava MORAJU biti jedinstvene po verovatnoći.
  • Prijavne karte MORAJU biti potvrđene samo za jedan pokušaj autentifikacije. Bilo da je autentifikacija bila uspešna ili ne, CAS MORA poništiti prijavnu kartu uzrokujući da svi budući pokušaji potvrđivanja sa tom instancom budu neuspešni.
  • Prijavne karte TREBA da počinju karakterima "LT-".

3.6. kolačić za dodelu karte

Kolačić za dodelu karte je HTTP kolačić[5] koji postavlja CAS nakon uspostavljanja jedinstvene prijavne sesije. Ovaj kolačić zadržava prijavno stanje za klijenta i, dok je validan, klijent ga može predstaviti CAS-u umesto prvenstvenih akreditacija. Servisi se mogu izuzeti iz jedinstvene prijave kroz parametar “obnove” opisan u Odeljcima 2.1.1, 2.4.1 i 2.5.1.

3.6.1. svojstva kolačića za dodelu karte

  • Kolačić za dodelu karte se MORA podesiti tako da istekne na kraju klijentove pretraživačke sesije.
  • CAS MORA podesiti putanju kolačića da bude što je više moguće restriktivna. Na primer, ako je CAS server podešen na putanju /cas, putanja kolačića MORA biti podešena na /cas.
  • Vrednost kolačića za dodelu karte MORA sadržati adekvatne bezbednosne nasumične podatke tako da se kolačić za dodelu karte ne može pogoditi u razumnom vremenskom periodu.
  • Vrednost kolačića za dodelu karte TREBA da počinje karakterima "TGC-".

3.7. podešavanje karaktera za kartu i za kolačić za dodelu karte

Kao dodatak gore navedenim zahtevima, sve CAS karte i vrednost kolačića za odobrenje karte MORAJU da sadrže samo karaktere iz skupa {A-Z, a-z, 0-9, i rastavni znak ?-'}.

Dodatak А: XML šema CAS odgovora

<!--



   The following is the schema for the Yale Central Authentication



   Service (CAS) version 2.0 protocol response.  This covers the responses



   for the following servlets:



     /serviceValidate



     /proxyValidate



     /proxy



   This specification is subject to change.



   Author:  Drew Mazurek



   Version: $Id: cas2.xsd,v 1.1 2005/02/14 16:19:06 dmazurek Exp $



-->



<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"



           xmlns:cas="http://www.yale.edu/tp/cas"



           targetNamespace="http://www.yale.edu/tp/cas"



           elementFormDefault="qualified" attributeFormDefault="unqualified">



    <xs:element name="serviceResponse" type="cas:ServiceResponseType"/>



    <xs:complexType name="ServiceResponseType">



        <xs:choice>



            <xs:element name="authenticationSuccess" type="cas:AuthenticationSuccessType"/>



            <xs:element name="authenticationFailure" type="cas:AuthenticationFailureType"/>



            <xs:element name="proxySuccess" type="cas:ProxySuccessType"/>



            <xs:element name="proxyFailure" type="cas:ProxyFailureType"/>



        </xs:choice>



    </xs:complexType>



    <xs:complexType name="AuthenticationSuccessType">



        <xs:sequence>



            <xs:element name="user" type="xs:string"/>



            <xs:element name="proxyGrantingTicket" type="xs:string" minOccurs="0"/>



            <xs:element name="proxies" type="cas:ProxiesType" minOccurs="0"/>



        </xs:sequence>



    </xs:complexType>



    <xs:complexType name="ProxiesType">



        <xs:sequence>



            <xs:element name="proxy" type="xs:string" maxOccurs="unbounded"/>



        </xs:sequence>



    </xs:complexType>



    <xs:complexType name="AuthenticationFailureType">



        <xs:simpleContent>



            <xs:extension base="xs:string">



                <xs:attribute name="code" type="xs:string" use="required"/>



            </xs:extension>



        </xs:simpleContent>



    </xs:complexType>



    <xs:complexType name="ProxySuccessType">



        <xs:sequence>



            <xs:element name="proxyTicket" type="xs:string"/>



        </xs:sequence>



    </xs:complexType>



    <xs:complexType name="ProxyFailureType">



        <xs:simpleContent>



            <xs:extension base="xs:string">



                <xs:attribute name="code" type="xs:string" use="required"/>



            </xs:extension>



        </xs:simpleContent>



    </xs:complexType>



</xs:schema>

Dodatak B: Sigurno preusmeravanje

Posle uspešnog prijavljivanja, sigurno preusmeravnje klijenta iz CAS-a do njegove konačne destinacije mora biti pažljivo. U većini slučajeva klijent šalje akreditacije na CAS server perko POST zahteva. Tom specifikacijom CAS server mora tada proslediti korisnika na aplikaciju pomoću GET zahteva.

HTTP/1.1 RFC[3] daje kod odgovora za 303: Vidi Ostalo, što pruža željeno ponašanje: skript koji prima podatke preko POST zahteva, kroz 303 preusmerenje, prosleđuje pretraživača ka drugom URL-u kroz GET zahtev. Ipak, nisu svi pretraživači ispravno realizovali takvo ponašanje.

Preporučeni metod preusmeravanja je JavaScript. Stranica koja sadrži window.location.href na sledeći način, izvedena je kako treba:

<html>



    <head>



        <title>Yale Central Authentication Service</title>



        <script>



            window.location.href="https://portal.yale.edu/Login?ticket=ST-..." mce_href="https://portal.yale.edu/Login?ticket=ST-...";



       </script>



    </head>



    <body>



        <noscript>



            <p>CAS login successful.</p>



            <p>  Click <a xhref="https://portal.yale.edu/Login?ticket=ST-..." mce_href="https://portal.yale.edu/Login?ticket=ST-...">here</a>



            to access the service you requested.<br />  </p>



        </noscript>



    </body>



</html>




Takođe, CAS treba da onemogući keširanje pretraživača tako što će podesiti sva zaglavlja koja se odnose na keširanje:

  • Pragma:bez keširanja
  • Keš kontrola:bez čuvanja
  • Istek: [RFC 1123[6] datum današnji ili prethodni]

Uvođenje prijavne karte je otklonilo mogućnost da CAS prihvati akreditacije koje su keširane i koje pretraživač ponovo pusti. Ipak, rane verzije Apple Safari pretraživača sadržale su grešku u kojoj je, upotrebom tastera za povratak, Safari mogao da se natera da prezentuje klijentove akreditacije servisu kojem pokušava da pristupi. CAS može sprečiti takvo ponašanje tako što neće automatski preusmeriti ako otkrije da je udaljeni pretraživač jedna od tih ranih verzija Safarija. Umesto toga, CAS treba da prikaže stranicu koja izjavljuje da je prijavljivanje bilo uspešno i koja daje link ka traženom servisu. Klijent tada mora ručno da klikne da bi nastavio.

Dodatak C: Reference

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, mart 1997.

[2] Berners-Lee, T., Fielding, R., Frystyk, H., "Hypertext Transfer Protocol - HTTP/1.0", RFC 1945, MIT/LCS, UC Irvine, MIT/LCS, maj1996.

[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., "Hypertext Transfer Protocol - HTTP/1.1", RFC 2068, UC Irvine, Compaq/W3C, Compaq, W3C/MIT, Xerox, Microsoft, W3C/MIT, jun 1999.

[4] Berners-Lee, T., Masinter, L., and MaCahill, M., "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, decembar 1994.

[5] Kristol, D., Montulli, L., "HTTP State Management Mechanism", RFC 2965, Bell Laboratories/Lucent Technologies, Epinions.com, Inc., oktobar 2000.

[6] Braden, R., "Requirements for Internet Hosts - Application and Support", RFC 1123, Internet Engineering Task Force, oktobar 1989.

Dodatak D: CAS Licenca

Copyright (c) 2000-2005 Yale University. Sva prava zadržana.

OVAJ SOFTVER JE DAT "U TRENUTNOM STANJU," I SVI ISKAZI ILI PODRAZUMEVANE GARANCIJE, UKLJUČUJUĆI ALI NE OGRANIČAVAJUĆI SE NA PODRAZUMEVANE GARANCIJE TRGOVINSKE PRIHVATLJIVOSTI I SPREMNOSTI ZA ODREĐENU SVRHU, IZRIČITO SE ODBIJAJU. NI UNIVERZITET YALE NITI NJEGOVI SLUŽBENICI NEĆE BITI NI U KOM SLUČAJU ODGOVORNI ZA BILO KAKVU DIREKTNU, INDIREKTNU, SLUČAJNU, SPECIJALNU, PRIMERNU ILI POSLEDIČNU ŠTETU (UKLJUČUJUĆI ALI NE OGRANIČAVAJUĆI SE NA TROŠAK NABAVKE ZAMENSKE ROBE ILI USLUGA; GUBITAK KORISNOSTI, PODATAKA ILI PROFITA; ILI PREKID POSLOVANJA) NA BILO KOJI NAČIN UZROKOVANU I NI PO KOJOJ TEORIJI O ODGOVORNOSTI, BILO PO UGOVORU, STROGOJ ODGOVORNOSTI ILI KRIVICI (UKLJUČUJUĆI NEMAR I DRUGO) KOJA PROISTEKNE NA BILO KOJI NAČIN IZ UPOTREBE OVOG SOFTVERA, I PORED PRETHODNOG UPOZORENJA O MOGUĆNOSTIMA TAKVE ŠTETE.

Redistribucija i upotreba ovog softvera u njegovom izvoru ili binarnom obliku, sa ili bez modifikacije, dozvoljena je pod uslovom ispunjenja sledećih uslova:

1. Svaka redistribucija mora uključiti obaveštenje o navedenim autorskim pravima i odricanje i ovu listu uslova u svakom povezanom dokumentu i, ako je izvodljivo, u redistribuiranom softveru.

2. Svaka redistribucija mora uključiti priznanje: "Ovaj proizvod uključuje softver koji je razvio Yale Univerzitet," u svakom povezanom dokumentu i, ako je izvodljivo, u redistribuiranom softveru.

3. Imena "Yale" i "Yale University" ne smeju se koristiti za odobravanje ili promovisanje proizvoda koji proisteknu iz ovog softvera.

Dodatak Е: promene u ovom dokumentu

4. maj, 2005: v1.0 - početno izdanje

2. mart, 2012: v1.0.1 - fiksni "noscropt" typo. apetro za amazurek, zasluge Farazu Khanu sa ASU-a za uzimanje typo-a.

Published (Last edited): 20-06-2013 , source: http://www.jasig.org/cas/protocol