Silverlight 3 + Azure + Security
- Hi,
I try to figure out , how to create a Silverlight application (full no asp.net) integrate a strong authentication (like Windows Live ID) and une Azure for calling WS. But it seem silverlight a too limitation to do that ...! Right ? or I miss read ?
It seem Silverlight application seem reside in Azure ... that's good
BUT
I thing a best practice is put WS behind a service bus ... but Silverlight can't call a SB directly... ?!
Second If a Silverlight authenticate with WLID it seem not possible ! ... or I didn't find how ... any sample exist ?
Comment : Webcast and sample about Access Control Stuff in .Net Service are very good ... but it's always about a solution credential Username ... I didn't find sample when you use WLID of other ...
Thanks for help...
답변
- The reason I linked the sample is because its supposed to give an example of using SilverLight to build a WCF client. With that done, you should be able to connect it to the service bus simply enough. As for the LiveID authentication, in theory (I haven't messed with ACS yet), you should be able to make a WCF call to the ACS to perform the LiveID authentication and get the claims back. Those can then be passed on to a web service or the service bus.
The other option (and one I'm more inclined to pursue) would be having silverlight pass the credentials to a web service that in turns does the LiveID authentication (via the ACS or whatever other mechanic you want to use). The WS then passes the authentication token and claims back to the presentation layer for cacheing in the user session.
I like this not just because I'm not a silverlight guy and have no idea how to do in it, but also because this does help seperate the presentation and business logic layers and easily allow you to reuse that service from multiple endpoints in your system.- 답변으로 표시됨Yi-Lun LuoMSFT, 중재자2009년 7월 2일 목요일 오전 10:08
Hello, it is very difficult to use active federation in browser based scenarios, especially when the STS itself doesn't handle authentication. For example, for your scenario to work, your Silverlight application will have to first work with Live ID using Live ID client authentication (which Silverlight doesn't support yet), get the security token, send it to ACS, and let ACS translate it to a claim for your service. All of those take a lot of effort to implement, and even if you're able to implement the whole system, it is very difficult to make sure there're no security issues in the solution.
But since your Silverlight application needs to call web services anyway, you'll have to host it on a web server. So unless your web server is only able to serve static contents, I think there's no reason not to consider a server based passive federation scenario. That is a well known solution, and you can find plenty of samples on the web on how to combine ACS, ASP.NET and Live ID. As Stephane pointed out, you can let ASP.NET handle the federation stuff, and make sure the Silverlight application is only accessible to authenticated users. To extend this point, you can save the user's claims in a session variable after the user is authenticated, and your WCF service can look into the session variable to control the access on the service side, at each operation's level. So ASP.NET only handles the initial STS related tasks and session, the remaining tasks (working with the claims) are still handled by WCF, whose programming model is similar to active federation.
By the way, Service Bus solves another problem: It expose your on-premise services to the internet, even if you don't have a public domain name or at least a static IP address. Service Bus itself has nothing to do with security and federation. ACS is for that.
Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.- 답변으로 표시됨Yi-Lun LuoMSFT, 중재자2009년 7월 2일 목요일 오전 10:08
The problem is mostly Silverlight's lack of support of the WS-* standards used to communicate with Geneva Server. I am not sure if the limited WSHttpBinding support added to SL3 is enough to request a token from a STS.
Using WPF, you will get the full WCF stack and you can do whatever you like. The only problem I see is the fact that you will have to handle authentication with LiveID through the Live APIs, not with Access Control Service, which can only be used with Live ID in web based scenarii.- 답변으로 표시됨Yi-Lun LuoMSFT, 중재자2009년 7월 2일 목요일 오전 10:08
모든 응답
- Not really ... This sample use solution credential for authenticated ... It's not possible to use W Live ID to do the same ?
- oops I guess is another sample (I already check)
Maybe ... I'll check that... - Ummm this sample is just a Silverlight hosted in Azure ... this seem relatively easy to do ... my concern is about authentification & permission about Silverlight / Azure (,net Service / Access Control)
Setup rule & permission in .Net Service seem ok for me ... but How I can create a Silverlight (or a Console application ) use Windows Live ID credential ... is it possible ? - The reason I linked the sample is because its supposed to give an example of using SilverLight to build a WCF client. With that done, you should be able to connect it to the service bus simply enough. As for the LiveID authentication, in theory (I haven't messed with ACS yet), you should be able to make a WCF call to the ACS to perform the LiveID authentication and get the claims back. Those can then be passed on to a web service or the service bus.
The other option (and one I'm more inclined to pursue) would be having silverlight pass the credentials to a web service that in turns does the LiveID authentication (via the ACS or whatever other mechanic you want to use). The WS then passes the authentication token and claims back to the presentation layer for cacheing in the user session.
I like this not just because I'm not a silverlight guy and have no idea how to do in it, but also because this does help seperate the presentation and business logic layers and easily allow you to reuse that service from multiple endpoints in your system.- 답변으로 표시됨Yi-Lun LuoMSFT, 중재자2009년 7월 2일 목요일 오전 10:08
... would be having silverlight pass the credentials to a web service that in turns does the LiveID authentication (via the ACS or whatever other mechanic you want to use). The WS then passes the authentication token and claims back to the presentation layer for cacheing in the user session.
But I have to acquire username/pw in a custome form and send back to server? (Silverlight to wcf service) is it clean ? do you really trust a Web Application use your LiveID ?- I think I see your point now. :) Bit slow today. Doesn't help that I haven't done squat with LiveID integration.
There are quite a few issues to do what you are planning to do :
- Silverlight has a very limited bindings choice to call a WCF Service. In SL2, you have only basicHttpBinding, in SL3 I believe there is partial support for WSHttpBinding. Service Bus uses special *RelayBinding, and to use ACS to provide integrated authentication you have to use WSFederation2007HttpBinding. I do not think any of those is supported in SL, and I don't think it would be easy to implement them manually...
- Live ID authentication is only supported with ACS using passive federation, which uses browser redirections to send the user to login.live.com to authenticate, and redirects back to your application with the security token containing ACS claims. There is, as far as I know, no way to use ACS to send the username/password to Live using a web service and get a token back. There might be something in the Live SDK, but that leaves us with the problem of the user trusting your app with his Live credentials.
- Last but not least, ACS is not supported in Azure yet (I certainly hope it will be someday...).
You could try to implement the authentication mechanism in ASP.NET, and have your SL application accessible only to authenticated users. You can use some hidden fields in your ASP.NET page to store some informations about the user (user ID, name...) and read those fields from your SL App.
Be aware that there is a gaping security hole in this : your SL code is accessible to the client, so he can tear it apart and fake his ID quite easily if he has a mind to. One possible workaround would be to generate some session ID in ASP.NET to make sure the User ID sent by Silverlight matches an active ASP.NET session. Another one is that Geneva Framework (used for ACS authentication) stores the user's identity in a cookie. You could read this cookie with SL, and send it along with your requests and have your web services check its authenticity. Note that this certainly isn't a bulletproof solution, but it can at least provide some security.Hello, it is very difficult to use active federation in browser based scenarios, especially when the STS itself doesn't handle authentication. For example, for your scenario to work, your Silverlight application will have to first work with Live ID using Live ID client authentication (which Silverlight doesn't support yet), get the security token, send it to ACS, and let ACS translate it to a claim for your service. All of those take a lot of effort to implement, and even if you're able to implement the whole system, it is very difficult to make sure there're no security issues in the solution.
But since your Silverlight application needs to call web services anyway, you'll have to host it on a web server. So unless your web server is only able to serve static contents, I think there's no reason not to consider a server based passive federation scenario. That is a well known solution, and you can find plenty of samples on the web on how to combine ACS, ASP.NET and Live ID. As Stephane pointed out, you can let ASP.NET handle the federation stuff, and make sure the Silverlight application is only accessible to authenticated users. To extend this point, you can save the user's claims in a session variable after the user is authenticated, and your WCF service can look into the session variable to control the access on the service side, at each operation's level. So ASP.NET only handles the initial STS related tasks and session, the remaining tasks (working with the claims) are still handled by WCF, whose programming model is similar to active federation.
By the way, Service Bus solves another problem: It expose your on-premise services to the internet, even if you don't have a public domain name or at least a static IP address. Service Bus itself has nothing to do with security and federation. ACS is for that.
Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.- 답변으로 표시됨Yi-Lun LuoMSFT, 중재자2009년 7월 2일 목요일 오전 10:08
- OMG ! I know why nobody won't be associate with security mess :)
Ok ... I won't do something with ASP because SL3 have a nice feature to install local ... and we want use it ... But *If* i understand (and it's not the totally truth :)
SL + Azure + Security == many problem ... I guess the new Azure stuff this will simplify (or at least give a platform for building secured and distribute stuff) but it's seem is not that ...
Maybe If the client is a WPF ... the gap is less than SL ... but my first goal is "all my stuff hosted in azure" ...
It's not possible to do that ?
SL --> call for authen to a STS (like WS) :: return a token
SL --> call SB / OR WS and supply token
WS match with ACS to manage role/claims by WS
If I replace SL by WPF Client ... is't possible solution ? The problem is mostly Silverlight's lack of support of the WS-* standards used to communicate with Geneva Server. I am not sure if the limited WSHttpBinding support added to SL3 is enough to request a token from a STS.
Using WPF, you will get the full WCF stack and you can do whatever you like. The only problem I see is the fact that you will have to handle authentication with LiveID through the Live APIs, not with Access Control Service, which can only be used with Live ID in web based scenarii.- 답변으로 표시됨Yi-Lun LuoMSFT, 중재자2009년 7월 2일 목요일 오전 10:08
