I'm new to ELK and want to perform authentication in kibana.
I have gone through the documents on LDAP and Native Realm.
Which will be the best one to do authentication.
Related
We use firebase to authenticate a frontend application in the standard process- The application connect to firebase and ask for token, than the application send this token in every API call to the server, and the server validates the token.
Now if we want to expose some of our endpoints and supply api access (e.g users will be able to login without browser), how should we do the authentication?
The users will send username and password, and we will need to authenticate against firebase with the credentials.
Is there best practice or guideline to how to approach this?
I want to still leverage firebase security features that I don't need to manage by myself (for example, preventing brute-force attacks), but not using the browser.
I'm building a multi tenant Service Fabric Application, that allows a tenant to specify a login type - Identity(asp.net)/Azure AD.
I have an Authentication service that checks to which tenant the user is linked to and then proceeds to check if the username:password for the user is valid, if valid it returns a JWT token to the gateway API/web API that then allows access to the rest of the services on the cluster.
This is further secured by roles to limit actions and data access etc.
Question 1
What would be a secure way to save the app id and secret given by that tenant if they use azure AD?
In my DB and encrypt the info, it would have to be decrypted to connect to the AD(Trying to keep in dynamic).
Question 2
I'm implementing my own sliding refresh tokens to obtain a new JWT after it expires, is there a better/standard approach?
Question 3
Is there a better/standard way to handle this multi-tenant sign in process.
Question 4
Is there a way to have optional claims set on the JWT Subject that would allow access to shared services but prevent access to tenant specific services if the claim value is incorrect?
Edit
Ideally the Roles should not be part of the tenants AD/B2C because they role are dynamic and managed from within the application.
Instead of building your own STS logic, have a look at IdentityServer, a popular and great OSS tool.
For example, have a look here for a multi-tenant example using asp.net core.
It supports adding custom claims to the token, by implementing a Profile Service. Services can be configured to use claims for authorization.
This blog post may also be useful.
I will very strongly advise you ride upon the Azure tenant model and let Azure AD manage all credentials and authentication. In today's world its a very bad idea to store and manage user credentials when there are plenty of Identity Providers available.
Recommended reading:
How to build a multi-tenant app with Azure AD
How to secure a Web API with Azure AD.
Libraries like MSAL.NET will automatically manage token caches and refreshes.
Use roles and groups in Azure AD
Claims in tokens issued can be customized to some extent.
disclaimer: I work for Microsoft
I would like to use Firebase Auth to authenticate mobile phone clients, but I have an existing PostgreSQL database with lots of functions and triggers that I do not want to convert to NoSQL. Is it possible to authenticate users with Firebase and then allow them to read and write data to the PostgreSQL database securely? What would be the proper way to do this? I come from a web development background so I'm used to session-based authentication instead of token-based authentication. Trying to wrap my head around it.
If you already have a backend talking to your PostgreSQL database, you can get a token with user.getToken() (https://firebase.google.com/docs/reference/android/com/google/firebase/auth/FirebaseUser#public-constructor-summary) and then verify the token on your backend (https://firebase.google.com/docs/auth/server#verify_id_tokens). Then, use the uid from the token as the user's ID.
I want to store some analytical information about the use of mobile apps into Amazon DynamoDb. I have the following requirements:
exactly one DynamoDb table per one mobile app
an app can do only PutItem method
all users of apps are unauthenticated (guests)
To provide to mobile apps a way to access a table in DynamoDb I see two options:
hardcode credentials with limited permissions into apps (permissions to do PutItem to a specific table);
use Amazon Cognito to get temporary credentials for unauthenticated users in runtime.
The second option Amazon strongly recommends as a much more secure. In my case a malicious user can either get access to hardcoded credentials or to a hardcoded identity pool ID with the same result: getting access to an AWS resource.
Question: does the use of Cognito in my case give any security improvements and if yes, how?
Cognito identity is totally free - you wouldn't have to pay anything.
Your point that using Cognito doesn't add any security to unauthenticated requests isn't correct. From the Cognito FAQs:
Q: How does Cognito Identity help me access AWS services securely?
Cognito Identity assigns your users a set of temporary, limited privilege credentials to access your AWS resources. You can use Cognito Identity to securely access other AWS services from your mobile app without requiring your AWS account credentials. You can also use the unique identifier generated for your app users in your Identity and Access Management policies. For example you can create a policy for an S3 bucket that only allows a particular user access to their own folder.
The same thing described for S3 can be done with dynamo - see this blog post for specifics.
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.