I'm working on a project created using Identity Server 4 for authentication, an API application that handles all the data and business logic and a client web app.
The IdentityServer project uses a different database for managing the users of the app and the API project has a copy of that table that gets synced with the one from IS when the user logs in.
The problem I'm facing is this:
When a user confirms his email the information is handled by IS but until his first login, the user appears to have his email unconfirmed in the API project.
How can I solve this without coupling the IS project to the API one?
I see various way to handle this.
Use messaging system to sync data (Users and it't update) between both the database.
Access DBContext of API project into the IS to manage users.
Or even simply have api to give updates to API project upon first login.
Related
I’m coding a Firebase application.
The user can only read the database and the owner can write in the database to add some content.
The owner would need an admin desktop application to upload data on the database (storage and database).
Since the application is a C++ app I would use python to communicate with Firebase.
I wanted to use Pyrebase or python-firebase but unfortunately these projects seems not to support the new database Firestore…
The rest API could work but... only with the Firestore database part...
My only way to add content to Firestore and storage is then to use the admin sdk.
I know that the C++ applicaiton will be used only on the owner computer but I’m worried about getting the service account file.
What would be the best way to use safely the service account file?
I thought to:
Encrypt the file with a password and then ask the password every
time the c++ needs to use the admin sdk (which technology would be
better for this?)
Download the service account file everytime the app needs (but where
to store it safely in the cloud?)
In order to use the Admin SDK with a project, you must have access to the service account credentials for that project. And with those credentials, you have full and unlimited access to the project. You should only distribute the service account credentials to users who should have such access, typically the collaborators on the project.
For application level administrators that are not collaborators on the project, I typically recommend setting up an administrative dashboard with a server-side and a client-side component.
The server-side component runs in a trusted environment, which for me often is Cloud Functions, but can also be a server you control, or even your development machine. This is where you use the Admin SDK to perform application administration actions, which you then expose in an authenticated end-point that client-side applications can call.
The client-side component is what the application administrator uses. For me this is often a very simple web page, but it can also be any other technology you prefer, as long as it can call the end points you exposed on the server.
The key here is that the server validates that the user that calls it is authorized to do so, before executing administrative actions on their behalf. With this approach, you don't have to give the service account credentials to a non-collaborator, and can revoke the administrator's credentials if needed.
I'm trying to authenticate my app users with their credentials used at the website
I managed to authenticate users via Xamarin.Auth to login via Google, Twitter... etc but could not figure out how to authenticate them via ASP.Net Identity provider.
any ideas or examples ?
Your problem is not a new one, and is one that will be easily fixed in the near future (see note below).
When you're authenticating with a provider like Google or Facebook, you're receiving a token that you can then use to send to the API. Unfortunately Asp.Net Identity does not do this out of the box. You can either configure your API to use JwtBearer tokens, or check out the Identity4 project along with their samples. Note that if you're using Asp.Net Identity you'll probably want a cross between Quickstart 6 and Quickstart 8 so that all of the necessary persistent stores are in your database.
NOTE: You might also want to follow the Templating Team's PR #700 which is adding token based auth in the new templates which will soon allow you to rapidly create new Api's with Token Based Authentication for your mobile apps.
I have a Web API and an Azure Web App that access the same database. This database has all user information. I'm using ASP.NET Identity for user management. I'm having an issue where when a user is created by the web app the Web API requires a restart, or at least a relatively long while before the user becomes authenticated by it. This, of course, is entirely impractical. How can I update the environment immediately on the Web API so that the user can access their resources?
UPDATE 3:
Turns out it WAS authenticating with the API, but I didn't hold the correct claims because my user was not associated with a Google account. See Answer below.
Wow. Nevermind. We require Google accounts to sign on one kind of client, and we SHOULD require it on the web client, but I haven't set that up yet. If an account is set up without an associated Google account, AND that email has a Google account set up on the client then it will try to authenticate with those Google claims that don't exist in the DB. So while I CAN authenticate with that claim through the Google SSO, there are no claims set up in the DB, resulting in 401 errors. Authenticated, but unauthorized.
This means my auth filter is probably misconfigured because it should not authenticate with Google if my account does not have an associated Google account, no matter what my client requests. It also means that I need to refactor my SPA on my Web App that statically calls for Google authentication with the API.
I am new to Identity server but I found it quite easy to set up.
Our goal is to implement SSO down the line but at the moment we are just moving our authentication logic out of application.
It is going good except I have one confusion.
When I set up the Idsrv, I had to create admin user as well as token requesting user. This was to access and configure Idsrv.
For application auth, I have to use Idsrv as federation server as well and authenticate users against some Asp.Net data store.
Now there is already one data store where Identity server specific users are stored.
Should I be using same store for my application user auth and created/edit these users in that store? Or can I/should I create a separate database for application specific users and use both?
At the minute, I am authenticating application users against Idsrv store.
I am not sure if I am logically thinking in right way to split these two user sets and calling one as Idsrv specific users. (We will have Identity service separately deployed for each application)
Thanks for your help in advance.
I've been playing around with ASP.NET Application Services. I've implemented the Authentication Service, Profile Service and Role Service successfully, able to log in and get Profile information for the logged in user and Role information.
Now I've noticed a major shortfall in the fact that I can't work out how to create a new user account with the Application Services stuff. Does anybody know how?
Seems like the Application Services AuthenticationService only supports validating existing users. You should enable creating users through some other part of your application, either your own web service or a web page.
I'm not sure about Application Services, but I know that you can create new users with Membership Services.
That's like this:
Dim mbmr As MembershipUser
mbmr = Membership.CreateUser(newUserName,newUserPwd)
There are something like 6 overrides for the CreateUser method.
I think not many people are not fully understanding the role of application services and thus feel frustrated when they do not find the full asp.net provider stack exposed over a store bought json endpoint......
Application services are exposed publicly. They are meant to provide an authentication and identification facility.
Think...
Your user is not logged in. To log in you must access application services to authenticate.
Right?
Do you really think that exposing membership management api such as Create/Delete user on that endpoint is wise?
Exposing management functions on a public facing api presents a huge challenge to get right for ONE scenario, much less to capably facilitate every scenario so perhaps you can see why application services exposes only what you need to do identify and authenticate a user.