I am developing Java application that uses Active Directory as user store. It is accessing AD using UnboundID LDAP SDK. Initially, I planned to use pool of connections that would bind to AD using service account and impersonate users as needed without requiring for user name/password to be entered again. Unfortunately, AD does not seem to support Proxied Authorization Request Control (RFC 4370). It does not seem to support SASL authzId field either "Additionally, it does not permit an authorization identity to be established on the connection that is different from the authentication identity used on the connection." from https://msdn.microsoft.com/en-us/library/cc223500.aspx
Is there a way to make my solution work without replacing AD with some other directory?
Use Case: We use Active Directory as an identity store for our users. When users log in we verify their credentials against AD by executing bind, which is followed by OpenID worklfow against our Authorization Provider. After that, user is considered authenticated and authorized and issued an access token. Everything is great until we get to self-service and delegated management part. We don't want users to see anything that they are not allowed to see/modify. We achieve that by managing permissions in AD. I.e. admin user can unlock accounts. Regular user cannot. If we use service account to perform LDAP operations we lose all of the extensive security model that AD provides. We are unable to maintain a persistent connection for each logged in user because the number of users is very large and we may potentially end up with thousands of connections. We would like to maintain a pool of connections authenticated with service account and impersonate users as needed. The easiest way to achieve it is using Proxy Authorization.
Related
I would like to authenticate against KeyCloak using "Direct Access Grant": https://www.keycloak.org/docs/latest/server_admin/index.html#resource-owner-password-credentials-grant-direct-access-grants
I works like a charm when keycloak manages users and passwords on its own.
But, my scenario is different:
I would like keycloak to act a Broker to some external IDP. KeyCloak has identity brokering feature - but in only works in "Authorization Code flow" - redirecting user to external IDP login form.
I have mobile app and would like ot use "direct access grant" - so that app comunicates with keycloak to authenticate user - and keycloak, as a broker, authenticates this user (using openid-connect) in external IDP
How to achieve such scenario ? I know that it is not possible out of the box - but maybe somebody could advice how write an extension to keycloak do make this scenario possible ?
Whatever it is you are trying to achieve this way, it goes directly against what OAuth and OpenID Connect were designed for. The whole idea of using access tokens is to allow some relying party (such as a mobile app) to interact with a service on behalf of the user without ever getting to see the user's credentials (like a password).
Think of it like this. Let's say you have some app on your mobile phone. It can make use of certain services by Google. In order to do so it offers you to log in with Google and grant the app access. Now, would you want to do so by putting your Google email and password directly into the app? Of course not. That could give it complete control over your Google account, other apps and sites using your Google identity, possibly services that allow you to pay through your Google wallet... It would be insane to simply hand some phone app your Google login.
So instead with OAuth2 or OpenID Connect you can use the authorization code flow or implicit flow to have the user redirected to the identity provider (Google in our example) where they will complete their login process, and then the identity provider redirects back to the app or a site with an authorization code that can be exchanged for tokens or, for the implicit flow, the tokens themselves.
Now, when it's your own app and your own identity provider (like Keycloak) which are under your control it doesn't really matter. You can use a direct grant to simply have the user input their username and password into the app because you know it's not trying to steal user credentials to maliciously use your service. They're both under your control. In that case OAuth or OIDC are a bit overkill, but you could have separate clients for direct grants (your own app) and authorization code flows (third-party apps using your service). When you want to use Keycloak identity brokering, however, an external identity provider like Google or Facebook is not going to offer a direct grant and invite apps to steal their user's credentials. So you won't be able to interact with them this way.
Depending on what you're trying to achieve you may find some use in the token exchange process. If however the idea is that you want your user to log in with their external identity provider credentials, in your app, without a redirect... Don't.
This is a real use case, unfortunately Keycloak doesn't have a direct way of solving this issue. AWS's "IAM Roles for Service Account" feature works based on token exchange with direct access grant using external IDP. I found this discussion on how to workaround this lack of support in Keycloak but not sure if it solves all the usecases - https://lists.jboss.org/pipermail/keycloak-user/2017-January/009272.html
Do you stick with Direct Access Grant as a method of user authentication in your mobile app? In my opinion, you need to use Authorization Code Flow when the IDP is a third party service as it won't provide an API to authenticate users, and even with your own (first party) IDP, it'd be better to use Authorization Code Flow as stated in OAuth 2.0 Security Best Current Practice section 2.4.
To implement Authorization Code Flow in mobile apps, you will need to use in-app browser tab to show login screen provided by the IDP. Please refer to RFC 8252: OAuth 2.0 for Mobile and Native Apps for details.
I'm in in process of looking to create an Android app; security is obviously the most important thing to keep in mind.
What is the best-practice for authenticating a user and handling business logic (scenario below).
For example, the current design would facilitate the permissions based on the user's login. When a user logs in and successfully authenticates, their Username and Password are stored in session variables. When the user attempts to request a resource that requires a certain permission to view, as part of the process for accessing the resource their Username and Password is sent up to the intermediary Web Service, if this authenticates with the correct permission-set the resource is then accessible.
Is this a reasonable way of operating an Android application or is there a better solution to handling this?
Thanks.
Presumably you're referring to building some sort of web API such as REST API that the Android App would send requests to and the API performs the database actions.
I wouldn't send the username/password combo for every request that tends to be bad practice. You send the user/password combo once to authenticate and the authentication returns some sort of token and this token is then sent in every request and is validated on the API side to ensure it is a valid session token. You could either roll this yourself or use some sort of Single Sign On (SSO) solution such as Google Sign on for example or OAUTH is a common authentication mechanism. Maybe https://oauth.net/ will help.
I have the hope to use the token generation and management abilities of Keycloak, without authenticating against Keycloak's users but instead, 3rd party systems that do not use token based authorization.
In other words, I want to create a realm that generates tokens not for Keycloak users but for that 3rd party's users, meaning that there is no need to store users in Keycloak's DB.
Is this even possible? If it is could anyone give me some pointers?
From what I've seen the closest ability that Keycloak provides is the Identity Providers option available the Administrator console. Unfortunately and as expected, it works only for OpenID Connect and SAML which of course are token based.
This question already has answers here:
CAS Server that supports Facebook/Twitter authentication via OAuth
(2 answers)
Closed 5 years ago.
What is the main difference between Single sign on and oauth.
If I build CAS server for Single sign on.can I use CAS server for oauth authentication in other application(ex.Facebook).
For your 1stquestion:
OAuth is an authorization protocol that allows a user to selectively decide which services can do what with a user’s data.
For instance, if you attempt to log into Spotify using Facebook, you’ll be redirected to Facebook’s website for authorization.
Single Sign-On, on the other hand, is a not a protocol — it’s more of a high-level concept used by a wide range of service providers (sometimes with confusing differences).
SSO is an authentication / authorization flow through which a user can log into multiple services using the same credentials.
For instance, at your company, you might want to use one set of credentials to access:
Your internal company website.
Your Salesforce account.
Your Atlassian account. etc.
Instead of making each employee at your company create different accounts for each of those services they use all the time, you can instead create a single account for each employee that grants them access to all of your company services. This is SSO.
So, OAuth is not about Single Sign-On. It is not about you controlling what the user can access.
It is about letting the user to control how their resources may be accessed by third-parties. Two very different use-cases.
CAS centralizes authentication.
Use it if you want all your (probably internal) applications to ask users to login to a single server (all applications are configured to point to a single CAS server).
I have a Java web application. It relies on Google OAuth to authenticate and authorize users. I want to provide an API to my application which must also use OAuth. Is it possible to provide OAuth by myself without having a database of users and auth mechanism?
Has it been implemented by anyone?
The OAuth specification doesn't make any particular statements about how to authenticate (ie, login) users - just how to pass credentials to other servers, once the authentication succeeds. There's no particular reason that, at the step where other servers might put up a login box, you can't instead initiate an OAuth transaction with another unrelated server.
However, you will need to have some sort of database to link up the credentials you issue (ie, the credentials your clients will use to operate your API) with the credentials you receive from upstream servers - whether this data needs to be retained over server shutdowns, etc, will depend on whether you want your third-party clients to be able to use their credentials over a long period.