I need to create a login page with a password reset workflow that includes sending a link to the user's email to the page to set their new password. I was thinking of using a Custom membership provider however, our system uses a back-end identity management system that all creation, validation and updates go through. All the examples I see for creating custom membership providers use a direct db connection. This will not work for me. So, I was wondering if it is advised, or even possible, to create a membership provider that does through a services back-end?
Sure, you can use services for your data access. You'll probably have to execute them synchronously, though.
Do you have the source and/or libraries for your identity management system? If so, you could access it directly in your provider, cutting out the service layer.
Related
I am working with Google Firestore in native mode and CRUD'ing data within it using the "cloud.google.com/go/firestore" api in Go. Access to the data is wide open as long as you know the project id and using the Firestore API on a server. I don't want to try the rules until I figure out how to secure the data from server attacks that. Again, all the API requires is the project id to access the data so I need to lock that down firstly before I move any further. Rules are only for mobile/web clients from what I read and Server side clients completely bypass the rules. Please help. I do not want to use the Firebase API because attackers can still use the Firestore api to access the data.
It's unclear from the limited information in your question but, your Firestore database is not open to anyone with the Project ID.
The service is only accessible to any thing (human|machine) that has valid credentials. Either humans with e.g. Gmail accounts or Service Account key holders.
In either case, only identities that you've explicitly added to the project will be able to access its resources and then only those with the appropriate IAM roles|permissions.
Google provides an elegant facility called Application Default Credentials (ADCs) that simplifies authenticating clients.
I suspect that your code is using ADCs to authenticate you to the project|service.
Access to the data is wide open as long as you know the project id and using the Firestore API on a server.
If that is a concern, consider disallowing all access in the Firebase security rules for your Firestore database.
Also have a look at my answer here to understand why sharing your project ID is not a security concern, and in fact is necessary if you want to allow direct access from client-side devices: Is it safe to expose Firebase apiKey to the public?. If you don't want to allow direct client-side access, closing down the security rules (as they are by default, unless you choose test mode when creating the database) is the way to go.
I have a Teams application (Tab). I am an ISV provider, and provide a multi-tenant application that is installed by customers via Teams App Store in their organizations.
How do I save settings for my application organization-wide for the customers? For example, CustomerA has installed the app and then CustomerB. I want some storage that would be unique for CustomerA and CustomerB and the app, and located in customer's environment. The settings I want to save are not per-user, but per-organization (tenant).
Somewhat similar to "App Data" folder you have in Windows Desktop for example.
Does such a storage exist? Does API for this storage exist?
A tab app is a simply a web application that you render inside of Teams. As a result, what the app does, and where and how it does it, is totally up to you. This includes any data storage you choose to have behind the scenes. For example, your tab could be built in PHP and use MySQL, or built in ASP.Net and use SQL Azure or CosmosDB. It's totally up to you, but you need to implement it yourself, as an ISV.
The important piece to differentiate clients, however, is being aware of the TenantId for each user, so you can look up which client's settings you need from the database. The most simple way to do this is simply the tid property on the Teams tab context. You can read more about that here. Unfortunately, because it's just accessed via Javascript, it's not entirely secure - for a more secure mechanism, you should be creating an Azure Application, and generating jwt tokens that you can authenticate against in your backend. It's a much more complex topic, but hopefully this answer at least gives the background you need. For more info on the security aspects (validating the token etc.), please see this question: How to restrict access to Azure Function to only allow requests from a custom Microsoft Teams App?.
I need quick help regarding Identity server.
There is a client requirement to not allow any public hosted application to directly talk to the database. In Identity server's case, the Identity server will be hosted publicly for token endpoint, and it queries the database for operational data (went for Db approach with reference tokens because IDsrv will be on NLB). Is there any workaround for this? or is this standard practice?
Thanks
If you don't want IdentityServer to talk directly to the database, you will need to implement & register custom implementations of ICorsPolicyService, IAuthorizationCodeStore, IClientStore, IConsentStore, IRefreshTokenStore, IScopeStore, and ITokenHandleStore, that call off to some an external app that can talk to the database.
Normal operating procedure is to have IdentityServer talk directly to the database. I don't see much merit in separating the two.
FYI: You don't need to use reference tokens if you are using load balancing. Check out the deployment docs.
We are trying to migrate a legacy intranet ASP .NET web app from "Forms" based authentication into a "Windows" based one so that the user doesn't have to enter the credentials again after logging into the PC, we just want to read the current logged-in identity and use that for authenticating and authorizing the user in the application.
Doing windows authentication in ASP .NET is pretty straight forward, what i wanted to check though was how the user's and their groups should be managed within AD or ADAM.
The same user can have rights on multiple environments of the same application like Dev, UAT, LT, Prod etc. so the same domain account needs to be authenticated in multiple environments (different URL). Also, once authenticated into an environment the user might belong to multiple roles which decide what actions are available for the user to perform.
I was looking for some recommendations here in terms of how we set this structure up in AD, we are thinking of creating groups in AD for the different environments like App_Dev, App_UAT, App_Prod etc. and have nested groups within each of them for the different roles in the application like App_Dev\Role1, App_Dev\Role2, App_UAT\Role1 etc. for each of the environments and add the users inside it.
What do you guys think?
You have to rememeber that Authentication and Authorization are two different things. You have combined them in your logic.
For example, your authentication mechanism is AD. So yes, use AD for authentication of credentials and group membership to ensure they can authenticate with a specific instance.
However, you can still use the classic RolesProvider and use a SQL backend to store roles and user to roles assignments per instance within the database. This is easy and uses the built-in feature of ASP.NET without having to go overboard with creating groups in AD. You can do various searches on the web about ASP.NET AD Authentication and SQL Roles Provider. I think ScottGu even has an old article about how to do it.
Lastly, what you have described here is not SSO or Single Sign-On, I'll update your question to reflect this. SSO refers to creating a token that is trusted and shared amongst many applications. It doesn't seem like you need that with the example provided, but if you do, you would be investigating ADFS and the Windows Identity Foundation (WIF). Just because you use AD does NOT mean you have SSO, it simply means you have a single Authentication Provider, but you still don't have a token based system that actually only requires an initial Authentication and Authorization request to a central authentication service, usually ADFS.
starting a proof of concept for this model it appears not to be possible to configure the membership provider per request to the respective clients database. It appears that the web application instantiates the membership providers on application start and doesn't allow modification to this during subsequent requests.
I have tried using reflection and modifying the connection string in the Application_BeginRequest (in the global.aspx) but it appears that the membership provider is designed and implemented to only initialise once per application rather than per request.
This implies for the separate database approach, the default asp.net membership provider wont work with the single application/multiple database (multitenant seperate database) model.
what authentication/authorization model do people use in this architecture? do they use a custom implementation of the Microsoft membership providers or do they use a different package or library?
Cheers
Tim
In the case of a multi-tenant application development scenario, the best preferred is a SSO or to go with a custom profile management system.
In order for you to enable tenant based authentication using the databases, you can have a connection string manager that identifies your tenant based on some of the criteria like the company code or the URL and then use the user login data from that database for that tenant's users.
The usage will be like you identify / infer the tenant code from the login credentials and then choose the database that is available for that tenant and then authenticate the user against this database. Hence the tenants can have their own databases for their user's authentication.
This is feasible and can also comply with the regulatory requirements that may be for different tenants based on their geography.