I need to build an application that manages users and I thought that it will be nice to follow an existing management model, like the one used by Windows or linux, that has users, groups, permissions etc.
I couldn't find any place on the Internet to get explanations about how to implement this.
My application is a web application, probably asp.Net (less important the technology) that manages users. I have few levels, for now system administrators, power users, group managers and simple users.
Each level offers privileges, like power users may see all the users, may promote a user to be up to group manager, may degrade a user (with less powers than his) etc.
There is any place where I can read about how to implement such system?
Probably using the ASP.NET membership provider will work for you. You can use the SqlMembershipProvider which stores the security information in a Sql Server database. If you need more advanced features (and probably more secure), you can use Active Directory or ADAM with the ActiveDirectoryMembershipProvider. The ASP.NET membership provider model is customizable and you can implement your own provider, but the existing ones are quite powerful.
Related
We have a suite of apps we are developing. We have already rolled the app out to about 50 users and have over 200 more. Sharing connections (custom connection & connector) and the apps have become super cumbersome. Long story short, this is a lot of time. Each time we have a new user we have to share 3 apps, 2x connections, and setup access on an internal method we have. We are using SQL, not CDS.
This has been misery. Is there a way to create 1x address that I would share with the Apps/Connection and I would just add users to this group? Would save us time to just add users to the one list. Then access is just shared via this common group. Does anyone know a better method to deploy powerapps like this? We can't share to "everyone". Thanks.
If you have an Azure Active Directory Security Group you can give them access to the connector and powerapp. See: https://powerapps.microsoft.com/en-us/blog/sharing-powerapps-with-multiple-users/
There are some kind of distinctions between Security Groups, Distribution Groups, O365 groups, and on prem vs Azure. I couldn't tell you the difference between them all, but you can follow Microsoft's instructions on how to share a canvas app which will go through some of these different methods of sharing.
I am designing the architecture for an Azure application, and I have a few questions on how to proceed. I am familiar with the basics of Azure, but have never built and deployed an Azure application before. I have extensive experience with conventional non-cloud, web-hosted applications, though.
My application will be the usual database-centric business system with a web user interface. We want to start very small and grow it slowly as we gain user base. I am planning to use an SQL Azure database for relational storage as well as blob storage for documents and the like. These will be accessed by a Data Access Layer, which in turn will be operated by a Business Layer. The web user interface will be built using ASP.NET and will rest on the Business Layer.
All this is very traditional, but I wonder how well it fits with Azure. I have some specific and inter-related questions:
I see the Data Layer and Business Layer as part of an Application Tier that can be deployed on a worker role, whereas the web user interface can be deployed as a Front-End Tier on a web role. Is separating the business and presentation logic like this a wise decision on Azure?
Having said the above, having two separate roles wouldn't make sense while the user base is very small, so I would rather deploy everything together on a single web role until we get bigger. What do I need to do to make sure that these two tiers can be easily reconfigured to work as either one or two roles with any recoding?
The communication between the web user interface and the Business Layer must be fast; I am concerned that it won't be very fast especially when these two are deployed as separate tiers on different web/worker roles. What is the best communications mechanism in Azure that I should use? I have considered queue storage, service bus and virtual network, but I am not sure how to make a decision here.
I have been reading some best practices posts and documents online, but they seem to address advanced issues. I would rather like to have answers to these quite basic concerns in the form of pointers to best practices articles or the like. Thank you.
I am having a hard time understanding Windows Azure service bus and access control concepts. In layman's terms, what are they? What are they used for?
The Service Bus component of Windows Azure is meant to handle the problems arising from services that are living in multiple networks. Basically, a service bus just makes it appear as if your code is running on a single machine, while in reality it could be running anywhere within the Azure datacenters.
Access Control lets you use "federated authentication for your service based on a claim-based RESTful model. (Sorry, copy&Paste from an O'Reilly book about Azure!)
Basically, when you create an Azure site, application or service, it could be running on any of the thousands of systems within the datacenter. And each of those systems has it's own IP address, it's own network, memory, processor and whatever more. To let them collaborate and to appear as a single system, these two services have been created.
If you want to learn more about Azure, this would be a good moment to buy a book! :-)
Azure is quite complex and service buses and access control are a bit more advanced topics.
Service Bus is a solution for the integration between multiple applications whether they are hosted on the same infrastructure or even spread along multiple infrastructure or/and Cloud Computing provider. If you search more in the internet you might find a lot about EAI (Enterprise application integration) here is my blog post about this topic:
http://hhaggan.wordpress.com/2013/03/07/introduction-to-enterprise-application-integration-eai/
and here another that I hope that helps you understand better what is the service bus:
http://hhaggan.wordpress.com/2013/03/09/introducing-service-bus/
in another words, it is a messaging platform that helps you communicate with multiple applications, softwares or services no matter what programming language they are written with or on which os or platform they are hosted on. you will feel its effect specially when you work on connecting multiple nodes together, I don't mean 5 or 6 nodes but 10 and above.
Certainly there are several types of service bus, whether they are based on relayed messaging service or brokered messaging service, each one of them has several uses, its purpose and way of working.
For the Access control, this is so easy, it is a way of authentication and authorization for your application using third parties, It is a claim based identity that you can do the required authentication through the third party database. you wont need to build everything from scratch in your database. this helps a lot during development and I believe that this can help a lot in social media marketing and branding because of the use of facebook, twitter during the authentication.
We are trying to create a SaS based portal using Liferay 6 for multiple (non related) organizations. And we want to go for a approach where we can generate these organization setup automatically based on user information.
We may require to have separate domains/websites for each organization.
As of now I have thought about two options for this
Portal Instance
Organizations
As per my understanding, i think this can be achieved by both of the above approaches. I would like to know your experience on both of these approaches on following points.
Which one would be easy to administer in long run
Which one can be easily programmed to create new setup automatically.
What about data security related to keeping in one portal instance vs multiple instance (is there any such thing?? not sure)
Any other approach to this?
Simple answer would be Portal Instances, since it was built for multi-tenancy.
Benefits to this approach would be that there would be segregation of data. Each instance maintains its own collection of users, communities, blog entries, etc.
Administration wise, there will be 1 account, the omni-admin, that can access all of these instances. On top that, each instance could have its own administrator that admins that particular instance.
Also, I don't believe using organizations will allow you to have separate domains for them.
Also going forward in Liferay 6.1, Organizations don't have pages only Sites have them, though we can mimic the behaviour with Sites.
Hope this helps.
I'm using Organizations for multiple sites, none of them sees each other, each one have their own users, roles, sections and communities.
Apache and Liferay virtual hosts url's makes the proper redirects to each organization home page.
For the admin I think is easier because in one control panel you can manage everything, or just the "scope" you want.
About using Instances, check the procedure to configurate them and see if you find it possible to create new ones automatically. Not very sure about that for organizations either, but having to touch portal-ext.properties may be worse towards automatization.
Regards
I want to set up TFS permissions to better reflect the responsibilities and levels of clearance of different roles within my organization; I'm finding that the default Reader and Contributor groups are too coarse-grained for my needs (and too loosely named).
To keep maintenance overheads to a minimum, I'm therefore thinking of replacing the Contributor and Reader groups with my own groups, but... is there any negative side effect of deleting those two groups? Does any part of TFS rely on them being there?
You should be fine. The built-in groups at the project level are for convenience only.
(This is NOT true of some of the server-level groups like TF Valid Users and TF Licensed Users. Maybe TF Service Accounts as well, I forget. These "well known groups" play a specific role in internal TFS operations. Delete them and the system won't work, even if you recreate them exactly as they were, because the GUIDs won't match.)
Just make sure that if you remove the Project Administrators group, you still have admin privileges inheriting from another group (eg TF Admins), otherwise you'll find yourself in a catch-22 situation. If you do get stuck by accident, know that local admins on the application tier machine are "TFS super-admins" who can bypass all security checks and put things back in order.
-EDIT-
One thing you will have to do is manually grant permissions to the new groups in Sharepoint and Reporting Services. I'd recommend downloading the TFS Admin Tool -- makes these tasks much simpler.