Transparent login to mobile application by logging in to WiFi hot

[SnS]

I am working on a windows mobile application which has to login to a
corporate network after the user has successfully logged into a 802.1x PEAP
enabled Wifi hotspot provided by the Service provider.

I dont want the user to type the username pwd again to login to the app
after he has logged in to the hotspot.

How to achieve this from a mobile app?

As per my understanding, once the user successfully logs in to the WiFi
hotspot, the device would recieve a digital certificate which would be stored
in the mobile device's cert store. The app has to retrieve the certificate
from the app store and attach it to the login request.

Is it possible to retrieve a secure signed digital certificate from the
device? If so, how to do that?

Is there anything else to be done apart from this

 

[Paul G. Tobey [eMVP]]

Well, *if* a certificate were stored in the certificate store, then you
could use the Crypto API calls to do various things with it (OpenNETCF's
Smart Device Framework has a cryptography wrapper that you could use).
However, I don't think that it's true that the server certificate, which is
sent to the device to *validate the server* is stored anywhere. Nor, I
think, are the cryptography items that are used to encrypt the
communications channel with the server stored anywhere.

Back up and give us the various scenarios that you have to handle. Here's
the only one we know about from your description:

1. When a secure, PEAP, connection is made to an access point, the
application should take that as a sign that the user has the right identity
and, therefore, the application should not require a second login.

Is that correct? So, what are the other cases? When the device is not
authenticated with the AP, you want to ask the user to log in? How do you
validate those credentials?

Paul T.

 

[SnS]

You are right in case 1. The other cases would be

1. When the device is connected to the some other WiFi spot provided by
some 3rd party provider, then the application has to show its own login
screen.

2. If at all there is some way to access the corporate network through
single sign on process , how do we make sure that ONLY my application running
in the device does that., no other app running in the same device should be
able to given access to the corporate resources.

 

[Paul G. Tobey [eMVP]]

You are right in case 1. The other cases would be

1. When the device is connected to the some other WiFi spot provided by
some 3rd party provider, then the application has to show its own login
screen.

How will you know that this is the case? SSID value? Or are you expecting
to be able to figure out that you are authenticated in some other way?

2. If at all there is some way to access the corporate network through
single sign on process , how do we make sure that ONLY my application
running
in the device does that., no other app running in the same device should
be
able to given access to the corporate resources.

Networking is networking on Windows CE. I don't think that you can do what
you're asking for. You might be able to write your application so that it
takes over the device, not allowing access to any other application that you
might find insecure, but, once an application is running, it can get to
anything you can get to. Windows CE doesn't support the fancy security
models of desktop Windows where an application can have an ability, while
another application does not.

If you can tell us more about what the device is used for and how it's used,
we might conceivably be able to come up with another method to do what you
want. That is, are you connecting to shared files? You're talking to an
SQL Server instance? Those sorts of things can be secured and, if your
application is the only one on the device that knows the passwords, because
you ask the user for them and use them to make the connections. Now, that
won't prevent the user from having to authenticate via PEAP, as well as
authenticate to your application, but it should properly defend the
resources.

Paul T.