We have AD FS 2016 fronting our corporate Active Directory domain for public OAuth2/OpenID Connect authentication. We are developing a simple application that is using our AD FS as an OAuth2/OpenID Connect identity provider.
Users authenticate via OpenID Connect and then on first use we provision a local user. On all authentications we store the access token.
There is a background service that sends out emails and SMS notifications to registered users based upon their local profile (which is initialized with info from claims from the IP). Using the offline access token, I would like to confirm that the user is still valid (not disabled) according to the IP (our AD FS server). Both the application website and the background service are NOT running within our corporate LAN. All access will strictly be through AD FS/OAuth2/OpenID Connect.
Is there a standard way using OAuth2/OpenID Connect to verify with the IP that an authenticated user (represented in the access token) is still enabled/valid?
The practical application of this is that if an employee leaves the company and their Active Directory account is disabled, we shouldn't send them notifications.
It feels like this is something that could be exposed via the userinfo endpoint exposed by OpenID Connect. You may need to set up some custom attribute->claim mappings to work it work but it should be possible.
Related
We have a Vaadin / Spring Boot application which should be accessible via a browser and without login from intranet only.
We would like to implement SSO with the Windows login (Active Directory).
The goal is high security with least configuration as the application is sold to customers.
I came up with the following scenario:
receive the IP address of the client accessing the Vaadin-Application.
Look up in the Active directory / Domain controller, which is in RW mode and see which user is online with this IP address in this very moment.
check the rights of this user managed by the Active Directory Groups.
make application available with logged in user for the client requesting it.
IP spoofing is not possible (as the connection is bidirectional, also users have no access to network devices.)
this login process is only done once to initiate the session.
Am I correct with these thoughts? Can you see any security issues? Is it really necessary to use certificates?
What would you recommend if so? Kerberos, CAS, x509, SAML?
One of my iOS apps contacts one of my services using Google Cloud Endpoints and I would like to restrict access to that service to instances of the app.
I've followed instructions about adding authorization and have created an iOS client ID that is tied to my app's bundle id and app store id. I've now difficulties understanding this part of the instructions:
If your iOS app is making calls to an Endpoint that requires
authentication, you must Add a Sign-in Dialog to your iOS client.
I do not want my users to log in but instead I want my app to present its credentials to the service for authentication without user interaction. I thought since the client ID is (presumably cryptographically) tied to the client ID and bundle ID only the app is (somehow) able to do so and that the client ID would effectively serve like a service account.
Is this type of app (not user) authentication scenario supported by Google Cloud Endpoints (for iOS clients) or do I have to roll my own app authentication by passing some secret in the application-level protocol? Here are some earlier related (unanswered) questions for Android clients.
I have concluded for now that Google Cloud Endpoints allows authentication only based on Google account credentials. What I need is a credential for the entire app (not its users) akin to a service account or an API key.
I have used service accounts for server-to-server communication. It does not seem possible to create service accounts for an app (as opposed to a GAE application).
GTLService has a property APIKey. However, if my client sets it to a public access key (iOS key) that I created for my GAE application in Google Developer Console the server returns error Access Not Configured. Please use Google Developers Console to activate the API for your project but there is no (obvious) way for configuring non-Google APIs such as my service API.
So until further notice I will add an API key to my application-level API requests and check it in each #ApiMethod.
Short version: Can my application authenticate itself with OAuth 2.0 without using a service account?
Long version: The issue I'm having with service accounts is that they can't be granted the same permissions as the original account that created them. Specifically, my company doesn't grant external accounts write permissions for security reasons. A service account is technically an application specific account, outside of the domain of the account that created it, and has more restricted access than an end-user account.
Is it possible for an application to authenticate itself as a user account?
Service account is allowed to impersonate a user to get an access token.
See https://developers.google.com/accounts/docs/OAuth2ServiceAccount#formingclaimset Additional claims section.
https://code.google.com/p/google-apps-manager/wiki/GAM3OAuthServiceAccountSetup has description for how to configure it.
For example: http://www.behance.net/dev/register
requires website name for registering desktop app, but what could possibly be the website for such app??
How to register such non-browser based app?
That URL requires credentials so I cannot see exactly what they're requesting, but it probably wants the application's redirection endpoint.
In OAuth, client apps not only reside on a resource owner's device, but they must also operate a server that knows how to participate in one or more of the OAuth grant processes. The point of requiring a redirection endpoint is so the access token can be transmitted from the authorization server to the client app's server without exposing it to the other applications running on the resource owner's device.
I have a Windows Phone application which is reading and writing data from a WCF Data Services service which is hosted in and ASP.NET MVC 3 application.
I can configure both client and server as necessary. I'd like to use OpenID if practical, and once a user is authenticated on the phone they should be able to browse through data which is associated with their OpenID.
How should I configure client and server to make that work?
To use OpenID in your app you should look at using an embedded WebBrowser control which connects to the provider site (or your site which can redirect). When the OpenID provider returns to your site (embedded in the browser control) you'd pass necessary identifiers back to the app.
There's an example of doing this with a twitter app (using OAuth) at http://blog.markarteaga.com/OAuthWithSilverlightForWindowsPhone7.aspx
OpenID is an awkward choice. It sounds like the user already has data associated with their account, which means that the user would have to login to the server at some point in time to set up this data, and then login to the app with the same credentials to access this data. The issue is that of securely verifying that the client app has indeed authenticated the user in question. Assuming that the client app (somehow) has the user's OpenID is not enough because the server can't implicitly trust what the client app tells it.
Off the top of my head, I'd say, what could be done with OpenID is as follows.
First, set up OpenID authentication on the server. Then, when the client app needs to authenticate, it should use the WebBrowser control to point to a server URL that, in turn, lets the user authenticate with their OpenID provider, and points the browser back to the server with the authentication info. At this point, the client app is unaware of the user's authentication status, but the server knows who they are. Now, the server can generate a single-use auth key for the client to use. It can redirect to a special URL with that key in it, at which point the client detects said URL, extracts the key, hides the WebBrowser control, and uses that key to talk to the server. I believe that would be a secure way to do such authentication, but like I said, this is just off the top of my head.