Another option for .NET is to leverage the Windows Identity Framework for authentication/authorization. You can federate with win-sts.stanford.edu and indicate a homerealm of idp.stanford.edu to access WebAuth. I have not actually tried building a client application using active profile - you may have to terminate the authentication at win-sts (Stanford's Active Directory)
-Ross -----Original Message----- From: webauth-info-boun...@lists.stanford.edu [mailto:webauth-info-boun...@lists.stanford.edu] On Behalf Of Russ Allbery Sent: Tuesday, July 17, 2012 11:21 AM To: Saray, Ray Cc: webauth-info@lists.stanford.edu Subject: Re: WebAuth and Client Applications "Ray Saray" <rsa...@stanford.edu> writes: > We are creating a client application in .NET that we eventually want to > allow users to login to if they have a SUNetID. We were wondering what > possible solutions there might be to allow this authentication: > . Does WebAuth have an OAuth solution (similar to what Facebook, > Google, etc. expose)? The .NET framework integrates nicely with this and > can bring up a browser within the client to get user information. Not currently. Something that we're investigating for the long term is to use OAuth 2.0 for the WebAuth protocol, but this is at least a year away. (But it is definitely something that we're looking at, precisely to support this use case.) > . We are hosting a remote service at Stanford for this client > application to hit. Is there any service exposed by WebAuth (or > potential access to LDAP) that would allow us to authenticate a username > and password without needing to go through a web page redirect? I'm afraid not. Interactions with WebAuth via any mechanism other than a browser are not supported. There are some people who are using various workarounds, primarily for monitoring, but they're not something on which one should build an application that needs to be robust. Our recommendation for the time being for authenticating a mobile application or other similar client applications to a web server is to not use WebAuth for that purpose. WebAuth is designed from the start for interaction with a browser; attempting to authenticate to WebAuth with a non-browser is just going to cause you pain. Instead, you should use a different authentication scheme such as client certificates or HTTP Negotiate-Auth that is designed for non-interactive authentication. If you're starting from .NET, then I recommend looking at HTTP Negotiate-Auth, which is natively supported on Windows platforms and which uses the user's existing Windows single sign-on credentials. I'm happy to provide more details if you want to explore that approach and can let me know what the server environment looks like. This will hopefully change in the future. My current tentative plan for a WebAuth 5.x protocol is to rework the protocol so that it's a profile of OpenID Connect built on top of OAuth 2.0, which would allow us to reuse quite a bit of existing infrastructure and make it much easier for applications to interact with the WebAuth system. But there are significant security challenges (the security standards of OpenID Connect are not yet up to what we want to provide with WebAuth) and significant development will be required to reach that goal, so it's not something for which I can provide a time frame. -- Russ Allbery <ea...@windlord.stanford.edu> Technical Lead, ITS Infrastructure Delivery Group, Stanford University
