I set up a Spring Boot project using https://start.spring.io including Spring Security and Vaadin. Then I set the Vaadin version to 22.0.4 and followed this tutorial to set up a login page using Vaadin Flow and Spring Security: https://vaadin.com/docs/v22/flow/tutorial/login-and-authentication
This works perfectly and checks login attempts against an InMemoryUserDetailsManager having a dummy user. As you can see in the tutorial, this is configured in the WebSecurity class, which extends VaadinWebSecurityConfigurerAdapter.
Now, I want to authenticate against Firebase users with email address and password instead. Therefore, I set up a Firebase project and added a user. I first thought, that the login can be done using the Firebase Admin SDK, but now I think this is not possible.
How can I authenticate Firebase users with email address and password in my Spring Boot application using Vaadin Flow as a frontend framework?
Firebase has two types of SDKs:
Its regular SDKs are designed to be used in client-side, untrusted environments, such as web front-ends, Android apps, or iOS apps.
Its Admin SDKs are designed to be used in (typically server-side), trusted environments, such as your development machine, a server that you control, or Cloud Functions/Cloud Run.
Only the regular, client-side SDKs have methods to sign the user in. For the Admin SDKs this is not needed, since they already run in a trusted environment and this establish their credentials in some other way (typically through a credentials file that you download from the Firebase/Cloud console).
So there's no way to sign in to Firebase on your server-side code. This also would not make a lot of sense, because a lot of users will likely be accessing the server at once, so who is the current user?
Instead, in Firebase you typically sign the use in client-side through one of the regular SDKs, and then (if needed) you pass the ID token to the server, where your code (through an Admin SDK if available) can decode that ID token and determine what user is making the request.
You can mint your own ID token in the Admin SDK, but the flow remains the same there and you typically use this to implement a custom sign-in provider.
Related
I have a Rest API developed with Spring Boot and neo4j as a database. There is no Frontend in the Spring Boot App. It only serves as a Backend. The Frontend is developed in Flutter.
In my app, the end user has to sign up and login with theis user credentials. The user management is currently handled with Spring Security and JWT, generating and storing the tokens with AuthenticationProvider, UserDetailsService and so on.
Now, we are migrating our whole infrastructure to Microsoft Azure. We already managed to get the DB, the Backend (as the Spring Boot App) and the Frontend there.
The question now is whether it makes sense to migrate the User Management to Azure Active Directory. Is this the right use case for that, or is Azure Active Directory actually there for other use cases?
Also, I want to use my Login and Signup Forms built with Flutter. I only found solutions so far where you get redirected to this Microsoft Login Form. I want to signup/login directly from my Flutter App, and then use the token for my requests in the Spring Boot App.
Does this even make sense? If yes, how can I realize that? I was searching for hours but I didn't find any proper solutions.
If you use AAD you will have to use the OAuth redirect based Microsoft login experience. There is no way around that.
If you can't think of any way you or your users will benefit by migrating to AAD, then there's no reason to do that. You're doing a bunch of work, and incurring risk, for no real benefit.
I have a mobile app which gets token directly from azure login. And I have a service which is using adal4j in spring boot. I cannot use the mobile generated token to authenticate spring service. Becase I use two different azure app registrations for mobile and web service. Is there a way to accomplish this ?
My understanding is that you have created 2 Enterprise Applications in Azure.
1) An Enterprise Application for your mobile app (Type: Native)
2) An Enterprise Application for your Web API app (Type: WebAPI)
For native app, you will not need a client secret but you will need a client secret for the Web API app.
Now coming to the key configurations:
In both of these, please update the manifest file to have oauth2AllowImplicitFlow set to true
Also, in your Web API Enterprise Application, please have the app id of your native app in the known client apps
"knownClientApplications": ["
Now, when calling your Web API through an end-point from the Native application, pass your token in your request header as "Authorization": "Bearer "
Also note: if you need to retrieve group claims, please update the manifest in both your enterprise apps to have the following setting for this property
"groupMembershipClaims": "SecurityGroup"
Update:
Under permissions in the native app, please add the Web API app registration to allow access
Yes, the OAuth 2.0 on-behalf-of flow should applies to your scenario. These steps constitute the On-Behalf-Of flow.
Azure AD issues a token for certain resource (which is mapped to an Azure AD app). When we call AcquireToken(), we need to provide a resourceID, only ONE resourceID. The result would have a token that can only be used for the supplied resource (id). There are ways where you could use the same token , but it is not recommended as it complicates operations logging, authentication process tracing, etc. Therefore it is better to look at the other options provided by Azure and the ADAL library. The ADAL library supports acquiring multiple access-Tokens for multiple resources using a refresh token. This means once a user is authenticated, the ADAL’s authentication context, would be able to generate an access-token to multiple resources without authenticating the user again.
Further details here.
I have an MVC application (.Net Framework 4.5) which is been there for the last three years and using Forms Authentication mechanism. This application provides different accounts like Personal, freebie, Enterprise etc. For an enterprise account, we are handling everything in the same application. I.e. Suppose an enterprise called “xyz” created an enterprise account with the application, then we are providing a custom URL like “https://application/xyz/login” and from the URL we are identifying that enterprise. I don’t know the exact reason why they implemented like this as I have seen applications that are having enterprise accounts are created as subdomains (e.g. https://xyz.okta.com). Now the client asked to integrate Okta into this application.
So I looked into Okta and found SAML is the right way to do and ends up in KentorIT Authservices. Initially, I was able to integrate this with a sample MVC application and the authentication part was working fine. With some basic idea about SSO, I have started integrating kentor authsevices into my application. The challenges I found in this implementation are:
1) For Enterprise accounts, Okta configuration settings are different for each enterprise and with my current application implementation, it is not possible to set it in from the web.config. So I have tried to set it from code and I was able to integrate those settings by replacing Configuration.Options.FromConfiguration;. I’m planning to store all configuration related things(Single sign-on URL, Audience URI,Identity Provider Issuer" etc.) in the database so that I can get the information whenever I wanted and I’m assuming that “Identity Provider Issuer Id is unique for each Okta account. In an IdP initiated flow, when the user tries to access the application it will redirect to AuthServices\Acs action method and from that, I’m trying to read the configuration settings. From the request is there any way I can identify from which Okta account call came(like Identity Provider Issuer)? Currently, I set the "Identity Provider Issuer" value (and I think which should be unique for okta account) to the Default RelayState field under General SAML settings tab and I was able to retrieve it from AuthServices\Acs action methods. Does it seem to be a good idea? Please advice.
2) The Enterprise accounts are limited based on the number of licenses (say 50). Suppose if the Enterprise Okta admin intentionally added 55 users all those users can successfully authenticate the application based on the default settings. Is there any way I can handle this scenario. Do I need to keep a record of the list of users that came under a particular enterprise account?
3) From the documents I understand that Kentor authentication service is only for authentication and authorization part has to be done from the application itself. The current application implementation consists of a custom authorization attribute which checks for user permissions that are stored in the database. That should be there as it is and we have to do the authorization based on database permissions. Right?
Expecting your valuable suggestions and please correct me if I'm wrong. Thanks in advance.
Don't use the RelayState for sensitive data unless you cryptographically sign it. It is not protected by any signature when using the POST binding, so the user may manipulate it. To get the issuing idp, check the issuer field of any claim generated by AuthServices instead.
Yes.
Yes, that's the whole idea with Kentor.AuthServies: To plug SAML2 authentication into the security model of .NET to allow you to use any current/traditional Authorization setup.
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.
I just create my first Okta application using a dev account.
The app supports saml2.0 to authenticate user.
My goal is to make Okta app as a smal2.0 IdP and having my on-premiesis web app acting as a SP. The flows works great.
As first step to test the flow I created a "user base"(people) in Okta.
Would it be possible to engage from Okta app a custom api (on-premesis) to validate the user credentials (supplied within the Okta built-in login page)?
IOW I'd like to use Okta app simply as saml2.0 IdP, managing the saml2.0 protocol, but I'd like to keep the user base locally.
We do provide SDKs to interact with our API, and you can find them at http://developer.okta.com/docs/sdk/core/api.html.
For instance, the Okta Music Store available at https://github.com/okta/okta-music-store demonstrates how you can authenticate Okta users in an ASP.NET MVC app and automatically provision them into a local database "on the fly" when they sign in.
I hope this helps!