All my questions may sound fool, but I'm learning keycloak, and I have some questions about it.
Is it ok to have 2 realms, one for my backoffice(staff) and other for end-users(customers)?
the realm staff will only login using google federation (will only accept email of my company), and I will use the power of SSO in all software my company uses, this realm won't allow self-signup. (for this case it's OK)
in the other side, the realm customer (for end-user), the registration is open for everyone, they can use google and facebook, as well as plain password and e-mail. Also my platform have a native app (iOS and Android), and the customers will login/sign-up via API (native login and signup screen with textfields)
Does it make any sense to use keycloak for customers?
Thanks
Related
We want to use SSO for a group of apps (this will include GitLab, probably Drupal and a bunch of small apps I will write in Symfony for various tasks). We would like to currently use Google accounts to authenticate all apps, but because there are limits (I know you can increase them) on how many apps you can have and Google sometimes change what features are free, it would be good to have the option of using our own login down the track if needed.
I have used SimpleSAMLphp in the past with GitLab (using a database to store credentials) and it worked well. Is there a way that I can use the Google Auth as an IDP and have SimpleSAMLphp record the email address to link the accounts etc and allow me to add things like groups etc in to send down to the app when a login happens? I would put a password field in the login table in the database as well so that if we decide to move away from Google we can generate random passwords and continue without too many issues.
The information I find online is for using SimpleSAMLphp as the IDP for gsuite etc (we will be using general Google accounts, not ones in gsuite) and not the other way around. I also couldn't see any Authentication Modules for Google authentication. Are there any tutorials or instructions anywhere on this?
You can accomplish what you are asking fairly easily. Instead of integrating your SPs with Google directly, integrate them with an SSP idP you control, then set up your authentication page (i.e. the page redirected to by your authsource module) to be an SP for Google. Here's what that looks like:
vendor sp -> your SSP idP -> your login app -> your SSP SP -> google idP
This way you end up with only a single Google integration configured for all your vendor integrations. There are numerous benefits to this approach:
You aren't affected by # of integration constraints imposed by google
Since your vendor SP integrations are controlled on your own server, you can easily move to a different cloud-based idP for authentication in the future without having to re-integrate all your SPs
You can easily give your users alternate sign-in choices if you want.
You aren't constrained to SAML or protocols supported by Google. Many vendors still use proprietary token based authentication. These can easily be supported with this setup.
Happy to help with implementation details if you need it.
Am a bit confused about the One tap sign in that was announced by google earlier this year. Our application already users Credential Management API in Chrome, which essentially provides the user with login options based on the credentials that user has saved for our site on previous visit (passwords that are saved in chrome). When I read the documentation for One tap sign in, it promises to do the same thing, but using Google's client api id. Our application has its own ID provider with our own database of user name and passwords, from the documentation it looks like One Tap sign in does not support custom ID providers. Can anyone shed more light on this, why would I use one against the other?
Thanks
Karthik
I see two major differences:
One Tap is passwordless - it uses a token based login that never exposes the user's password. Chrome Credential Management API stores and retrieves actual passwords in Chrome's password store.
One Tap is purely web based - Chrome Credential Management API relies on Chrome's specific implementation. One Tap is a purely web based workflow so it will work across browsers.
One Tap is a much better long term login solution in my opinion. The Credential Management API is experimental and currently only supported in Chrome.
https://developer.mozilla.org/en-US/docs/Web/API/Credential_Management_API#Browser_compatibility
I lead product development at Google for the one-tap/auto sign-in library, we designed it such that the library includes the Credential Management API and extends to provide assistance in account creation, secure passwordless, and cross-browsers support.
In particular, if you make a request for existing credentials with code like this:
googleyolo.retrieve({
supportedAuthMethods: [
"https://accounts.google.com",
"googleyolo://id-and-password"
],
supportedIdTokenProviders: [
{ uri: "https://accounts.google.com", clientId: "CLIENT_ID" }
]
});
then any saved username/passwords from the Credential Management API will be returned (in browsers supporting the API) along with token data for Google Accounts. The one-tap/auto sign-in JavaScript library wraps the Credential Management API for credential retrieval.
Furthermore, the library provides a googleyolo.hint method to show an email selector for one-tap selection of a verified email address to assist in new account creation, or to link to an existing account, and then be auto signed-in next time with token instead of password, across all browsers, so long as the same Google Account is active.
I'd suggest using the one-tap/auto sign-in library and consuming tokens as well as passwords in order to get assisted sign-up, keep existing users signed-in automatically, and provide functionality even if the browser does not support the Credential Management API.
As for the question about using your own database of username / password, the hope with this library is you could implement the ability to create accounts and auto sign-in to these and existing accounts with an OpenID Connect ID tokens representing the user's identity. With the one-tap / auto sign-in UX, these are not only much more usable, but far more secure then passwords and mitigate creation of weak/re-used passwords. Please consider this or, even better, a hosted auth solution like Firebase Auth or Auth0 and include the one-tap UX in the frontend UI.
I apologize if this has been answered, but I have been searching for hours, and still don't quite understand. This is a specific question, and not a "which is best" question.
Specific questions are in italic.
I have created a RESTful API, which was at first meant to be completely open. However, the organization has now decided to create a first-party mobile app to consume and (to some degree) update the data.
I am investigating authentication frameworks (oAuth2), and was not sure if oAuth2 was the correct way to go to meet our goals. And, if it is, which Authorization Grants applied to which set of users.
Our goals are:
To allow users to login and create accounts in the first-party app, entirely through oAuth 2 providers (twitter, facebook, google). These users would have access to the greatest set of data via the first-party app.
Assign different roles to the users (admin, moderator, etc).
Allow other applications to register, receive token credentials, and have limited write access or expanded access to the data. This would open them for creating third-party apps or research systems.
Finally, we would like to keep some of the data completely open, with no authentication needed.
So, am I right in assuming that we want to setup an oAuth2 *Server* (Authorization and Resource Server)?
If so, which Authorization Grants apply to the above situations?
One last question: For users using the first party app, would the app be responsible for logging them in and keeping their access credentials? The API server serves NO html, and is 100% RESTful. Does it need to serve login forms?
If you need to both authenticate and authorize users to your API based on various OAuth2 social logins, you do need some kind of API server or service where you can define your users and groups/role and the scopes that are available to users based on your rules.
Some cloud-hosted options for this are:
Auth0
Firebase
If you integrate with a service such as the ones above, you can let the service take care of authenticating users and just make sure that every user call checks against the service first for permission before it goes ahead and does anything.
Can Google Sign-In be used on an iPhone app in conjunction with Touch ID? If so, how? I cannot find any examples of this being done or talked about online.
Apps can incorporate TouchID as a means to locally authenticate a user.
Basically, the TouchID system can be queried and will let you access items in a keychain or do a simple one-off authentication.
If you stored Google account credentials in a local keychain, you could use TouchID to unlock the local keychain item, and then pass that item to a Google service for Google's authentication.
The keychain item in question (a password) would have to be enter manually at least once by the user (and at that point, it is probably more straightforward to just request an reusable authentication token from Google).
TouchID is entirely a local system, no fingerprint data is ever exposed to third party developers or pushed to a network, so Google couldn't store a fingerprint in their servers and allow direct authentication against their services using TouchID.
Here's the framework reference for Local Authentication:
https://developer.apple.com/library/ios/documentation/LocalAuthentication/Reference/LocalAuthentication_Framework/index.html
The Local Authentication framework is best suited for either confirming a logged in user in an app where the user may be logged in between many sessions (such as for a purchase in a shopping app) or local authentication for local documents (such as for password protected note taking apps).
I'm working in a company that uses Microsoft Active Directory. We have an external company that provides an internal web site for a particular project. The site is external to the company. The sign on to the external site is the user's company email.
We want a system whereby the external site calls into the organisation's AD to verify if an email address is still valid or if the user has left the company. It should be a simple call to Active Directory Federation Services or some sort of SAML interface. The call would be a simple request 'here's an email, is it valid?' and the response is either yes or no.
Our IT department are trying to tell us that it's too complicated and I don't believe them. I think they just don't want to do it.
Does anyone know how easy it would be to create a simple system that would allow an external service to do the query outlined above.
ADFS is not meant to do that. However, a by-product of using it, would be the validation you are looking for.
The first question would be: what is the authentication method of your app? e-mail and what else? password? which password? Does the app keep a database of users/passwords?
ADFS works as an "identity provider" and would authenticate users in AD. ADFS would supply a security token that can be consumed by your app. Part of the information sent in the security token could very well be (and often is) the user e-mail address (that's why it is a "by-product").
For this to work, the app would have to be changed to accept security tokens (SAML tokens to be specific). If the app is .NET based, then it is done usually with WIF (WIndows Identity Foundation).
This approach would be the most elegant and secure because the app would delegate the responsibility of authenticating users to the authority of these employees: AD.
App --trusts--> ADFS --authenticates--> AD
Setting up ADFS, etc is not super-difficult, but it is not super-simple either, and might not be worth just for this app. There are other lighter weight alternatives: open source products like Identity Server, or products like the one I work on.
Now, if all you need to do is to validate that the e-mail actually exists, the best is to send a verification message to that address with some unique code that the user sends back. This is the same approach used in many common web apps.
Agree with everything #Eugenio said - have same questions about authentication.
But if you simply want code to query an user's email address in AD, you use the AD API's.