...as opposed to just a user? To put it another way, if a user installs an app, will it always be added to the environment such that all other users can use it (assuming they've been given permission)?
Short answer: yes. Installed applications (AppExchange, or other) are always installed on a full Salesforce environment. However, User Profiles, Permission Sets, or Licenses may restrict access to the application.
If the installed application is licensed, and the User has a license, and the User's Profile has access to the necessary objects, tabs, code, etc., they will be able to use the installed app. By limiting permissions, an installed app can be completely hidden from Users.
Related
I have a (not so small) project started with ReactJS and Firebase web SDK - and I would like to somehow manage (at least add & delete) users in my system.
I am totally aware, that there is an Admin SDK, but I wouldn't like to transition to that in the current phase of the development. I would like to go on with the web SDK.
I have seen this nice workaround regarding the user-addition - and I managed to create & insert users with that.
Now, I need a way to delete or suspend users (at least), if possible. (I don't need strictly to have the update option, I can live without that.)
Do you now any way / workaround to that - similar to the point 2. ? Any idea how to achieve that?
The mobile and web clients for Firebase Authentication are not capable of changing the status of an arbitrary user account. A user account only has permission to delete itself, not other accounts.
You will need to use the Admin SDK for that, from a backend or desktop system you control. Initialized with a service account, it will have privileged access to manage user accounts.
It seems that DNN is undergoing an upgrade and I cannot access the forums or many of the docs. Needing an answer soon, and Google providing too many varied types of hits (none of which are helpful or most of which post to the DNN site that is undergoing that upgrade), I had a few questions about setting up DNN.
First, I am coming from Orchard. There I was able to use Webmatrix - I downloaded the web version, opened as administrator, created modules, messed with themes, etc. Using the Orchard Docs, I was able to set up a multi-tenant site and run it on local host (IIS express through Webmatrix) - this included modifying the host/config files to view the multi-tenant sites. I could then publish to my own server running IIS 7. On the server I set up the landlord site then bound the tenants with no problem.
Being new to DNN (and things not being readily available at the moment on their site), I was hoping I could get some guidance on how to set up DNN similar to what I did with Orchard.
First question is obviously whether or not that is possible (i.e., no IIS, only IIS Express (Webmatrix) on my local machine).
Here would be my other questions:
If I can run it locally, can I just download the 7.1.0 new install package, and open Webmatrix (as Admin) on the folder I unzipped it in?
Assuming I just "Run" the website, I will then set up the "Landlord" instance of DNN on the following screens, correct? (i.e., where it asks for credentials and what DB setup I can use)
Can I then go ahead and create sub-tenant sites (alias/portal)? If so, do I go about manually updating my host/config files to run those tenants (depending on the port)?
Assume all of the above is correct, do I have to "reinstall" the 7.1.0 package on my webserver, or will a simple publish from Webmatrix do (with the proper credentials in Settings)? If so, I can handle pointing to the landlord on my server and then binding my subtenants in IIS.
Sorry for the n00b questions. Thanks!
On the Download page on dnnsoftware.com, there's a link to click which will start the install process within WebMatrix: http://www.microsoft.com/web/gallery/install.aspx?appsxml=www.microsoft.com%2fweb%2fwebpi%2f2.0%2fWebApplicationList.xml&appid=106
When you create a new portal, you can specify that it uses a URL which is a subdirectory of the current URL (i.e. a child portal alias), so that you don't have to use different ports. I'm not especially familiar with IIS Express, so I would expect that you could point multiple ports to the site, and map those as different portal aliases, but not sure exactly how you could do that, if you don't want to make use of child portal aliases.
To publish a site, you should just need to push the file system and database, and setup IIS.
I'm about to start development work on .NET 4.0 winforms application running on top of a Microsoft SQL Server 2012 database.
The number of users supposed to use the application might be any where between 2 to 10 and the application should be able to run either on a single stand alone computer or in an intranet in a windows environment.
in case the application is run on a single computer, each user would log into the application (not into windows) and perform what ever tasks they are authorized to do and then log out of the application.
If the application is configured to run on a small intranet, each user would log into the application from there respective office computers and do what ever they are authorized to do.
So, the application can run on a single none networked machine, where a single windows login account is being shared by staff at the facility but i have a requirement to allow access to certain application functionality depending on who is logged into the application, NOT who is logged into windows as the account might just be shared.
I have previously deployed ASP.NET applications in networked environments and used the SQL Membership, Roles and Profiles provider for authentication and authorization While for winforms apps, i have relied on active directory authentication.
Now with this particular project, i am wondering what the best solution might be. Probably some one here has implemented a solution for such a scenario and can give advice.
I have looked at this http://www.codeproject.com/Articles/27670/Implementing-Application-Security-with-Client-Appl solution but i still want to hear from the SO masses.
ALSO, any recommendation for a better post Title is welcome.
Once I worked in a WinForm application which was supposed to run on intranet, each user would log into the application....and this application was using centralized web service to authentication and other CRUD operation....The service was mediator between WinForm app and DB.
The approach given in code project article which u mentioned in question...is also fine.
Anyway I also got curious here....As you said u are about to start development in .Net 4.0 Winform.....I would like to understand why you made this choice over WPF? What reasons u got to favor WinForm in your scenario ?
Yesterday I got a call from a Microsoft representative asking if we supply "hosted solutions", presumably as part of the big Windows Azure push. As soon as I got off that call, our marketing director came into my office and said the majority of our customers are demanding Active Directory integration in the next version. Then it occurred to me: how does one use Active Directory in a "hosted solution" if the application does not live on the customer's network?
As a more general question about Active Directory integration, what kind of functional changes does that usually imply for an app? Does it mean a user is signed into the app just by authenticating to Active Directory or does it mean the app gets its list of users from Active Directory or does the creation of new users or groups in the app create new users or groups in Active Directory?
Am I just caught in the crossfire of a war of buzzwords?
You're not. Active Directory can be run across the public Internet, though this complicates the security and setup of the network rather considerably.
Generally, authenticating an app against Active Directory means that your membership provider (for example) would call into Active Directory to do the authentication and, after that, the user is simply logged in; you don't keep active credentials, etc, in your own database. However I would consider it smart to cache that information as well, and be prepared to authenticate against that cache in addition to the directory, in case the domain controller is unavailable for authentication (an especially large risk if you're running the directory across the Internet).
You can use Active Directory Federated Services to enable authentication using AD over the internet between two organizations. See: http://technet.microsoft.com/en-us/library/cc786469.aspx
I've never used it only read about it. Hope it helps.
The accepted answer explains the role of Active Directory and I agree that caching basic user information may be useful in many instances.
Active Directory can be expanded outside of a corporate network, to the internet and connected web services. As another user mentioned, this is achieved through ADFS (Active Directory Federation Services) which allows "trusted" connections to be set up between separate authentication services. There were a number of scenarios explained as part of the "Office 365 Jump Start" webinars:
http://technet.microsoft.com/en-us/edge/office-365-jump-start-04-microsoft-office-365-identity-and-access-solutions
After viewing these, I immediately thought that a "hosted" AD and ADFS service would be useful, where a customer doesn't want to maintain the AD servers internally (Microsoft don't recommend running less than 5 seperate servers if you're doing this!) Recently, Microsoft have also launched their Azure cloud platform. One of the services they provide is labelled "Identity" which you can see here:
http://www.windowsazure.com/en-us/services/identity/
This is Microsoft's own solution to hosted AD services. In fact, they even mention using their "Identity" hosted service as a solution for SSO (Single Sign-On) for Office 356 and even Google web apps.
I am still learning about AD and Microsoft's cloud offerings, but I hope this points you in the right direction.
There's an article here: http://www.developerfusion.com/article/121561/integrating-active-directory-into-azure/ which describes in-depth how to integrate Active Directory with Azure - hope that helps.
Active Directory can be run across the public internet but you will experience lag times which may cause your app to time out or crash depending on your bandwidth. In the past, I have setup accounts with another company called ultradns.com who specializes in these types of scenarios. hope that helps.
You'd be best off going with a true hosting framework if you would like any support from MS.
I'm sure you'd like some links so:
HMC (Hosted Messaging and Collaboration)
The ONLY true blog I know about on the framework is from Kip Ng
The ASP.NET forums are a good resource for questions on the Framework as well.
An example of the work that goes into configuring AD for Exchange multitenancy is here, though it is based on an older version of the framework a lot of the same principles apply.
Also, try searching on the keyword multitenancy for some articles.
I am developing a web based intranet for my company. I just want to know is it a good thing for users to login the application using the active directory login details or shall i create a login together with the application db.
If there is anything better that this please suggest. This is my first application development so need help from experienced people.
Generally it's a good idea to try and minimize the number of accounts people need to have.
So I'd definately try and use their active directory login.
Also if desireable, you can automatically log people into your application using various single sign on methods. (Either integrated into IIS, or other.).
This makes for a very usable application, as people always forget login details, and hate to login again to other systems.
Only use Active directory for your intranet, if you infrastructure supports it.
You question is phrased as if you think the user to type there password in again to login to the intranet site - they should not do this! have windows pass on the credentials automatically. This is pretty much built in to dotnet/iis/etc.
Also AD will add group management a privledges so you can restrict areas of you intranet to members of certain groups.
And you support team already have the tools to manage all this.
PS you can enable FireFox to auto log on via NTLM and it is one of the most requested features for Chrome too so don't let browser issues put you off
There are several pros using Active Directory authentication in the intranet.
Thoses are the main ones:
You want to to keep authentication stores number as low as possible
Using Active Directory, users who have their desktop in the domain (as they should) will be able to use Integrated Windows Authentication. They will be able to log in without having to type their password.
An Active Directory authentication mechanism probably exists for your language
More information:
http://msdn.microsoft.com/en-us/library/ms998358.aspx
If you create a separate login system, then your users have to remember 2 different logins. Why bother, when their "real" login is right at hand?
Less code for you to write and better integration into the wider system. And, who doesn't want FEWER passwords to remember.
Definitely go for the Active Directory option, or use Active Directory as an LDAP server if whatever language you're using doesn't directly support AD. Active Directory actually makes a pretty good LDAP server.
If there is anything better that this please suggest.
OpenID?...