ACS zainstalowany, ale MVC 4.0 aplikacja nadal przekierowuje i nie znajdzie Login.aspx

Question

pierwszy post tutaj na stackoverflow ale uwielbiam stronę! ...

Mam pomyślnie utworzony w pełni funkcjonalnej aplikacji Azure model hybrydowy przy użyciu MVC 4. Opublikowane i działa świetnie. Teraz chcę dodać ACS dla auth do mojej strony. Śledziłem all the steps, ale po uruchomieniu aplikacji w symulacji nie udało się przekierować do ACS i oferuje stronę stwierdzającą, że nie może znaleźć pliku login.aspx.

Stworzyłem proste rozwiązanie internetowe, aby udowodnić, że mój ACS jest poprawnie skonfigurowany i działa dobrze. Zauważyłem, że pliki web.config obu rozwiązań były szalenie różne.

Ktoś próbował już to zrobić? Każda pomoc będzie doceniona.

----------- --------- Rozwiązanie

I w końcu wszystko działa. Kluczem było usunięcie odwołań do WebMatrix.WebData, ponieważ nie musiałem wykonywać własnego autoryzacji. Poniższy kod pochodzi z MVC4 Release notes.

Gdy plik WebMatrix.WebData.dll znajduje się w katalogu/bin aplikacji ASP.NET MVC 4, przejmuje adres URL do uwierzytelniania formularzy. Dodanie zestawu WebMatrix.WebData.dll do aplikacji (na przykład wybierając "Strony WWW ASP. z komponentem Razor" przy korzystaniu z okna dialogowego Add Deployable Dependencies) zastąpi przekierowanie logowania uwierzytelniania do/account/logon zamiast/account/login zgodnie z oczekiwaniami domyślnego kontrolera konta ASP.NET MVC.

Answer 1

Otwórz swój plik web.config.

Znajdź węzeł Uwierzytelnianie.

zmienić z:

<authentication mode="Forms" /> 

Do:

<authentication mode="None" /> 

komentarz tutaj, jeśli to nie pomoże, a co jest wynikiem po zmianach w pliku web.config.

Jako pytanie dodatkowe - w jaki sposób dodano odniesienie do przestrzeni nazw ACS - poprzez "prawy przycisk myszy -> Dodaj odwołanie STS" lub ręcznie zmieniono plik web.config?

Upewnij się, że wymagane Moduły są zarejestrowane w serwerze WWW:

<system.webServer> 
    <modules runAllManagedModulesForAllRequests="true"> 
     <add name="ClaimsPrincipalHttpModule" type="Microsoft.IdentityModel.Web.ClaimsPrincipalHttpModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" /> 
     <add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" /> 
     <add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler" /> 
    </modules> 
    ... 
</system.webServer> 

również upewnić się, że masz sekcję microsoft.identityModel i masz węzeł federatedAuthentcation w nim:

<federatedAuthentication> 
     <wsFederation passiveRedirectEnabled="true" issuer="https://[your_namespace].accesscontrol.windows.net/v2/wsfederation" 
         realm="http://127.0.0.1:81/" requireHttps="false" /> 
     <cookieHandler requireSsl="false" /> 
</federatedAuthentication> 

Gdzie "realm" będzie prawidłowym adresem URL dla Realying Party Application. I requireHttps = "false" ma na celu uproszczenie procesu programowania.

Podczas debugowania go lokalnie, upewnij się, że prowadzenie projektu Cloud (który używa IIS), a nie projekt WWW (który będzie korzystał Cassini/webdevserver, który nie rozumie sekcję system.webServer!)