Har ett litet problem som jag gärna skulle vilja ha hjälp med en lösning till... Jag har flera olika webbapplikationer som ligger å tuggar på olika servrar, alla kräver inloggning... Vad jag önskar är att ha en gemensam inloggning till alla, med forms då... Som det är nu så har jag en applikation som erbjuder dels en sida där en användare kan logga in, samt en webservice... Vad jag vill är alltså att min "inloggnins service" utfärdar giltiga tickets till andra sidor...

Är jag ute å cyklar eller är inte detta fullt möjligt att bygga? Å isåf förslag på lösning... önskar inte kod, bara tillvägagångssätt...

Jag och Olof diskuterade detta i chatten och här är vad jag informerade honom om. Du kan inte dela cookies mellan olika domän, det skulle vara en säkerhetsrisk men man kan däremot kunna dela cookies mellan olika webbapplications som ligger under samma domän <b>*.mydomain.com</b>.

Vad man behöver göra är att sätta <b>machineKey</b> i web.config till <b>EXAKT</b> samma för alla webbapplications under samma domän. Dokumentationen för machineKey ger oss följande information.

<code>
Configures keys to use for encryption and decryption of forms authentication cookie data and view state
data, and for verification of out-of-process session state identification. This section can be declared at
the machine, site, and application levels, but not at the subdirectory level.
</code>

machineKey skall placeras i rooten på <b>system.web</b> i web.config filern

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.web>
    <machineKey validationKey=".........." 
            decryptionKey=".........." 
            validation="SHA1|MD5|3DES"/>
  </system.web>
</configuration>

Vad olof vill göra är att kunna logga in på en av sina tjänster och sen surfa "inloggad" mellan de olika tjänsterna som han har som olika webbapplications i IIS. Märk väl att detta är inte som passport då passport kräver dig att logga in på varje sida med samma username&password som valideras mot passport (man kan använda an gemensam webbservice) och tillåter dig dela inställningar (en form av roaming-profile) mellan de olika passport sidorna (kan hämtas från webservicen efter inloggning).

//Andreas

Jag förstår inte riktigt varför inte en passport-lösning skulle fungera. En sådan lösning tillåter väl att man surfar "inloggad" mellan olika tjänster och applikationer?!?

Om man inte vill använda cookies (och inte kan använda passport), borde någon form av krypterat värde i querystring:en kunna användas för autentisering.

/PK

<b>En sådan lösning tillåter väl att man surfar "inloggad" mellan olika tjänster och applikationer</b>

Nej.

<b>krypterat värde i querystring:en kunna användas för autentisering</b>

Visst så länge som man bara surfar mellan tjänsterna. Inte om direkt surfar direkt till tjänst en via adressen och sen till en annan tjänst via dess direkta adress. Lite information från www.passport.com ger oss följande

<b>*</b> Använd ETT inloggningsnamn och lösenord på alla .NET Passport-webbplatser och tjänster.

<b>*</b> Lagra personlig information i din profil för .NET Passport. Om du vill kan du automatiskt dela din information med MSN-webbplatser när du loggar in, så att de kan erbjuda dig anpassade tjänster.

//Andreas

Jag har inte direkt örnkoll på passport-autentisering. Jag trodde att själva finessen var att man slipper logga in mer än en gång.

Jag förstår hur man kan använda cookies för just detta, men detta förutsätter ju att alla applikationer ligger under samma domän. En lösning med en extern tjänst (web service) hanterar väl även applikationer under olika domäner?

Vilka lösningar används egentligen i t.ex. företagsportaler som kör flera olika webbapplikationer (från olika leverantörer) med gemensam inloggning? Förutom MS passport känner jag till Novell e-directory. Jag misstänker att man oftast använder en sådan standardkomponent (eller tjänst), som de olika leverantörerna kan implementera stöd för.

/PK

Passport kostar för det första 10 000 USD + 1500 USD / sajt att få tillgång till.

Sen är Passport bara ett sätta att kunna identifera sig likadant överallt. Inloggningen följer inte med runt.

f.ö.
(e-directory == active directory) != passport

Vill man dela inloggningar så blir det som man sagt innan, man får styra sin kaka och hantera det utifrån de begränsningar en kaka har.

En annan variant är att bygga en egen IE plugin som skickar med användarnamn och lösenord automatiskt till alla siter, lite som MSN messenger och IE jobbar tillsammans ibland.

Tack för bra info!

Så om olika leverantörer av webbapplikationer ska kunna stödja en gemensam inloggning så gäller det bara för dem att veta vilket cookie-värde som ska kollas.

Jag hade nog missförstått det där med passport. Jag trodde att det var en teknik snarare än en produkt och att sålunda vem som helst gratis kunde sätta upp en egen passport-server för internt bruk. Vill man använda en sån lösning får man väl istället bygga samma sak själv och kalla det för något annat än passport. Det är väl detta som brukar benämnas Single Sign-In (SSI) eller Single Sign-On (SSO)?

japp men som det står längre upp. Cookies är domänbundna.

så www.cornerstone.se kan aldrig läsa kakor skrivna ifrån www.cshrp.net oavsett om de domänerna hostas på samma server eller inte.

Tack för alla förslag=) Men som nämdes, passport kostar pengar, har inte sådant... Men det är ju typ det jag vill ha... Men bygge följande lösning...

Alla applikationer har Forms Auth å loginUrl är satt till en sida på en annan applikation som har hand om identifiering, aka passport. Så när användaren skickas till den sidan får han ange uid/pwd, som i sin tur verifieras emot databasen... Via en "krypterad" querystring så skickas användaren tillbaka till den sida han kom ifrån tillsammans med de uppgifter han fyllde i, ja liten säkerhetsrisk... Samt ett guid som leder till ett "sessionID" som ligger i en db... Sidan som skickade användaren till "passport" sidan har nu då alltså uid/pwd, som det använder när det roppar på en webservice som skickar tillbaka en FormsAuth... å vips så är användaren verifierad...

Är lite mer än vad jag beskrev nu, de olika sidorna som kan använda verifieringen kallar jag för services, å varje gång en användaren anländer till "passport" sidan så kontrollerads det att den anlände ifrån en av dessa services...

Å när användaren loggar in på "passport" sidan så lagras det även där en cookie, som gör att när användaren kommer till sidan nästa gång, förmodligen igenom en annan service som använder passport grejen så görs bara en koll ifall cookien finns, å ifall det stämmer ifall användaren har rätt att använda sig av servicsen...

Hör gärna lite kritik eller komplimanger för min lösing=)

Att köra en webservcie som sparar en cookie anser jag en ok lösning. Har själv gjort en egen liten "Passport" på detta sätt. För att få en global singel signon lösning.

Dock bör du nog köra med SLL, och du behöver ju inte skicka med en massa data i queryn? Om du går mot webservicen från login på alla dina webapps så vet du ju vilken webapp du är på? det enda du vill veta av Webservicen är en true eller false... Inloggad eller ej. Sedan sköter ju applikationen resten.

Jag lagrar då en hashdata i cookien som jag verifierar för att verkligen se att jag är signerad. På så vis får jag hyffsad bra säkerhet, kan även slänga på SSL för bättre resultat (dock går det lite slöare då.)

Mvh Johan

Med risk för att jag har missförstått problemet.

Du kan väl göra en inloggningssida som arbetar mot en DB. I databasen lägger du in en kategori där olika behörigheter anges. Sen bygger man bara upp en DB-driven meny som genereras utifrån vem man är och vilken kategori man tillhör, och då kan man även göra cookies efter det.

Ex:

Adm Pers1 Pers2

Sid a Sid b Sid b
Sid b Sid c
Sid c