Azure ACS - najlepsze wdrożenie

Question

Cześć, budujemy aplikację ASP.NET MCV 3 od zera działającą na Windows Azure. Informacje o warstwie Uwierzytelnianie i autoryzacja są przeznaczone do korzystania z usługi kontroli dostępu. Przeszedłem przez kilka artykułów na temat ACS, gdzie otrzymałem podstawowy pomysł, ale wciąż mam pewne wątpliwości.

Rozumiem, że korzystając z ACS, zlecamy proces uwierzytelnienia jednemu lub kilku dostawcom tożsamości (IP), zasadniczo ufamy innemu systemowi (np. Microsoft Live ID) w celu uwierzytelnienia naszych użytkowników. Podstawowy proces jest bardzo prosty: na etapie uwierzytelniania przekierowujemy (ACS to robi) użytkownika do jednego z naszych "zaufanych" adresów IP, który przekieruje użytkownika (z ważnym tokenem) do ACS i ostatecznie do naszej aplikacji. Nadchodzi szereg pytań ...

Ponieważ nie chcemy, aby wszyscy użytkownicy posiadający konto Live ID mieli dostęp do naszej aplikacji, zakładam, że powinien istnieć inny proces sprawdzania tego użytkownika i sprawdzania, czy jest on zarejestrowany w naszej aplikacji. Pytanie jest gdzie? W ACS lub w naszej aplikacji.?

Mam pomysł na ten temat, ale nie wiem, czy to właściwy sposób: Na etapie rejestracji system (nasza aplikacja internetowa) pyta użytkownika, który adres IP (np. Identyfikator Live ID, Google, Facebook i nasza aplikacja.) Chce użyć do uwierzytelnienia się w aplikacji. Następnie użytkownik przechodzi proces uwierzytelniania w systemie IP, a kiedy wraca, przechowujemy jego nazwę użytkownika (nazwę użytkownika IP) w naszej bazie danych. Następnym razem na etapie uwierzytelniania możemy sprawdzić, czy dany użytkownik jest zarejestrowany w naszym systemie.

Jeśli powyższa teoria jest poprawna, oznacza to w naszej aplikacji. musimy zbudować naszego dostawcę członkostwa, aby przechowywać nazwy użytkowników pochodzące z adresów IP i użytkowników, którzy wybrali naszą aplikację. łyk. Czy mam rację? Jaka jest najlepsza praktyka projektowania powyższego procesu?

Porozmawiajmy teraz o autoryzacji i "rolach". Jak to działa z ACS? Czy ACS obsługuje wiele ról na użytkownika?

Znowu rozumiem, że dzięki ACS można utworzyć wiele "grup reguł" powiązanych z adresem IP, a nie z pojedynczym użytkownikiem. Jeśli to prawda, w jaki sposób zarządzamy użytkownikami w roli w naszej aplikacji? Załóżmy na przykład, że mamy wiele ról, a nasi użytkownicy mogą być przypisani do tych ról, czy możemy użyć ASC do zarządzania nimi?

Ostatnie pytania to: Czy sam ACS obejmuje cały proces uwierzytelniania i autoryzacji? Czy nadal potrzebujemy korzystać z usługodawcy .net? Jaka jest najlepsza praktyka, aby pokryć nasze wymagania?

Wielkie dzięki za Twój wkład.

Answer 1

Proces sprawdzania użytkownika odbywa się z roszczeniami.

Po skonfigurowaniu adresu IP z ACS, po uwierzytelnieniu użytkowników, ACS otrzyma roszczenia dotyczące uwierzytelnionego użytkownika z IP. Musisz skonfigurować reguły w ACS, aby określić, które roszczenia chcesz przekazać do swojej aplikacji. Możesz także przekierowywać roszczenia do różnych typów, aby znormalizować zestaw roszczeń przychodzących do tego, czego oczekuje twoja aplikacja. Jeśli chcesz wdrożyć swój dostęp oparty na rolach z ACS, możesz.W takim przypadku rola to tylko kolejne roszczenie, które ACS wystawi, a Ty zaimplementujesz swoją aplikację, aby nadać uprawnienia użytkownikom na podstawie roszczenia do roli, które otrzymuje z ACS.

Można skonfigurować reguły ACS, które odwzorowują określone roszczenia wejściowe IP na roszczenia wydruku ról ACS ma również usługę zarządzania, która może zmienić te reguły, aby umożliwić wdrożenie procesu rejestracji użytkownika.

Reguły indywidualnych roszczeń w ACS dotyczą dostawców tożsamości, którzy wystawiają roszczenie, ale grupy reguł nie. Grupy reguł kojarzą się z RP (twoje aplikacje). Grupa reguł to po prostu grupa reguł transformacji oświadczeń informujących ACS: "w przypadku tej aplikacji zastosuj tę zasadę grupy reguł podczas wydawania tokena".

Docs ACS mają wiele do powiedzenia na temat ACS konfiguracji reguł zastrzeżenia, zarówno za pośrednictwem portalu internetowego i poprzez usługi zarządzania ::

https://msdn.microsoft.com/library/azure/hh147631.aspx

Expanded odpowiedź:

Powiedzmy cię używam ACS do uwierzytelniania w aplikacji ASP.NET korzystającej z WIF. Skonfiguruj ACS, aby wystawić roszczenie do roli "Menedżera" dla użytkownika google pocztą elektroniczną "jdoe@gmail.com".

Teraz w twojej aplikacji ASP.NET, WIF zobaczy to roszczenie ról i pozwoli ci kontrolować dostęp za pomocą HttpContext.Current.User.IsInRole ("Manager") lub odpowiednika web.config.

Możesz zarządzać tymi regułami ACS ręcznie przy użyciu interfejsu internetowego lub możesz wdrożyć proces rejestracji, który dodaje takie reguły do ​​programu ACS programowo za pomocą usługi zarządzania ACS. Niektóre przykłady usługi zarządzania ACS są dostępne na stronie acs.codeplex.com.

Ponadto, zestaw treningowy deweloper tożsamość ma kilka przykładów WIF ról dostępu w oparciu o:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14347

Answer 2

Dla części pytania o etapie rejestracji, najlepiej użyć do identyfikacji użytkowników jest NameIdentifier Typ roszczenia:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier.

Powinno to być unikalne dla każdego dostawcy tożsamości, a także być stałe. Jeśli użyjesz roszczenia do adresu e-mail, może zmienić się dla tego samego użytkownika. Technicznie może to być możliwe dla dwóch dostawców tożsamości, aby korzystać z tego samego NameIdentifier (żaden z out-of-the-box te z OZW nie), więc można łączyć roszczenia NameIdentifier z typem IdentityProvider roszczenia

http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider

, aby zagwarantować wyjątkowość.

Jeśli chodzi o część dotyczącą roli, chciałbym powiedzieć, że używanie ACS do wydawania oświadczeń o roli z ogólnej tożsamości, takiej jak Google, byłoby dość trudne do zarządzania przy użyciu zasad transformacji roszczeń w ACS dla każdego użytkownika. Będziesz musiał dodać regułę dla każdego zarejestrowanego użytkownika - prawdopodobnie nie jest to wykonalne. Sądzę, że grupy reguł ACS lepiej nadają się do transformacji roszczeń o role (np. Wydanych przez stowarzyszony program ADFS). Twoim pomysłem na zrobienie tego w twojej aplikacji jest lepsza IMHO. W kodzie miejsce do tego przy użyciu WIF jest niestandardowe ClaimsAuthenticationManager.Zastępujesz metodę Authenticate i bazujesz na roszczeniu NameIdentifier z zasady przychodzącej, wyszukujesz w bazie danych członkostwa i tworzysz nową IClaimsPrinciple w oparciu o role, które są w DB twojej subskrypcji (tj. Dodajesz roszczenie do roli dla każdej roli użytkownika jest w).

Następnie podejmuje decyzję o autoryzacji w niestandardowym ClaimsAuthorizationManager. Istnieje kilka dobrych próbek i informacji na ten temat w Internecie. Można zacząć w

http://msdn.microsoft.com/en-us/library/ee748497.aspx