I'm just getting started with a website based on Orchard and have a question related to user accounts and authentication.
There will be site administrators/editors of various kinds responsible for updating the site with content. For these types of users the built-in role and user management in Orchard is a perfect fit. Regular site users, however, must be stored in an external legacy system, should never have access to the site dashboard and should not be visible under the "Users" tab in the dashboard even to administrators (they are managed completely by the external system).
What would be the proper way to implement this in Orchard?
Implement your own membership provider. You can take examples from the gallery that are doing authentication, such as oAuth or AD modules.
Related
We have a SharePoint 2010 extranet web application that uses claims authentication.
The Intranet zone is using mixed authentication (NTLM against internal AD and FBA against a separate AD).
The Extranet zone uses FBA only against the separate AD.
We have sites that have NTLM users in the Members SharePoint group. We have librarys with "Person" colums limited to the Members group. We would like to allow FBA users to pick NTLM users that are in the Members group when fillng in item metadata. The problem is that the FBA users can see the NTLM users in the people picker but when they select them, the user is not resolved. I realize we could probably work around this by adding NTLM to the Extranet zone but prefer not to do this if possible.
My questions are:
Is this a scenario where a custom claims provider would be appropriate?
Is this a problem that could be resolved with the peoplepicker-searchadforests property? (I've not been able to get my head around a real world example where this property is in play)
This is how I understood that the people picker works. I'm not 100% sure so don't take it for absolute truth :)
Basically, in the context of the Extranet application, all standard pickers are completely unaware that the internal AD exists. The "hits" you get in the people picker are found in SiteUsers list and/or profile database.
"Is this a problem that could be resolved with the peoplepicker-searchadforests property?"
I don't think so, I think that even if you are able to make the people picker search other ADs might give some pretty weird results, like being able to add a persons permission to some object, but with the FBA claim prefix, which does not equal the user when logged in using NTLM. (A user signed in with NTLM and Claims is technically different users.)
"Is this a scenario where a custom claims provider would be appropriate?"
I don't think so :(
One trick that you can do for people picker that YOU create (i.e. you have a custom page or webpart or something with a people picker), there are several properties you can set to change from where the users are retrieved. For example you can set a property like "WebApplication" or similar that basically make the picker work as if in the context of the internal application despite the current user being logged in on the external app.
What I'm thinking is maybe there is some way to enable the NTLM membership provider on the extranet application, but without actually enabling end user authentication with it. It doesn't sound impossible but I'm not sure exactly how that would be done though.
I'm curious about the best/most efficient way to do this.
I've already set up my sharepoint 2010 site, and it is configured to use FBA. What i'd like to do is allow users to create their own accounts by filling out a form (the form will sit on a public sharepoint site, and filling it out creates a user in the membership database which is used for validation to enter the FBA sharepoint site).
I'm familiar with using the asp CreateWizard tool to build user accounts as part of a .Net web application, but I'm not sure on how to develop this as a webpart for use in a sharepoint site, as a webpart doesn't have the config file to store connection string and membership/role provider info.
Can this user creation form be put in a webpart and deployed to other sites, or is there another/better way to add this functionality to sharepoint (allowing users to register/create their own FBA accounts for access)?
There's nothing not much difference between SharePoint and regular ASP.Net for this.
The membership provider will need to be configured in the SharePoint web.config, including connection strings. However, it does not actually need to be used for login, so you can still create users in that membership provide from a different site.
I use a slightly different approach though - set up an anonymously accessible page in your site (in layouts is probably easiest, though a page within a site may be better for branding) and put controls on that page to create (and log in) a new user. You will need to call EnsureUser and possibly CreateUserProfile to give the new user access to anything, but aside from that it's all standard .net.
We're currently investigating what kind of authentication we want to use for a sharepoint portal site : Forms Authentication or Windows Authentication. The latter has my preference.
What suprised me (I'm a sharepoint noob), is the fact that MS didn't provide a component/web-part that handles account management when using Windows Authentication.
Do you now how to do this? Without resorting to buying an additional product. Shouldn't it be very easy to access the Active Directory by code (C#)?
Windows Authentication
I echo Justin's thoughts regarding AD management. Adding users to your domain also doesn't necessarily have anything to do with adding them to SharePoint. However perhaps there is an IIS add-on that does this if you wish to pursue it.
If you don't already know, SharePoint can automatically import user profiles from your Active Directory domain. This makes them available for assigning permissions within the sites.
Some additional info from Justin's comment about changing the AD structure to administer security: With SharePoint 2007 you no longer need to rely on Active Directory to manage groups of users. It's possible to also use SharePoint groups (which can contain AD users or AD groups). This works really well when you need to create a group for a purpose that isn't applicable outside SharePoint and you don't want to bug the infrastructure team. The downside is that without education, end users probably won't manage this well and it can become a mess.
Forms Authentication
It's true there is very little provided by Microsoft for managing this. However the Community Kit for SharePoint provides this functionality. From memory I had to tweak their code a bit but I was generally happy with it.
If you are considering this option also read this MSDN article.
It's much easier to just use the regular AD management tools provided with Windows rather than trying to manage your users' permissions through a web interface (for groups and such).
...of course you'll need access to make changes to your AD structure to administer the security.
Another alternative you may want to consider is using Forms Authentication using the Active Directory provider. It'll allow you to use the Forms Auth user admin tools and still authenticate against an Active Directory environment.
IF this is for users who are not a part of your actual domain (i.e. extranet users), I suggest you take a look at ADAM, Active Directory in Application Mode. It behaves the same as regular AD, can be administered through the windows.
Also, take a look at the following codeplex project, ADSelfService, it allows users to edit their own AD profiles. Perhaps you can extend the code yourself to allow admins to edit all profiles.
AdSelfService Project
We want to implement SSO functionality in our organization, but we're not really sure what our options are, and what the benefits / disadvantages for the different solutions might be.
-We have multiple old ASP(Active Server Pages) sites which should use SSO
-We have multiple ASP.net web-Applications which should use SSO
-We want Sharepoint to use the SSO
-CRM (Biztalk?) integration (Additional information about the user, such as Address, company, etc )
Since we're primarly .net, c#, Microsoft oriented, my first idea was to use Active Directory.
I've also noticed that there is something called ADAM (Active Directory Application Mode), and ADFS (Active Directory Federation Services), but I can't really say I understand when/where these should be used.
Here is a brief overview of the different web-applications
-"My Personal Page" : User log's into an application where they can modify their personal information along with their company-information and their employees. (Asp.Net)
-E-learning application (ASP)
-CMS system for web-publishing (ASP.Net)
-Sharepoint sites
I haven't really been able to find any articles that can tell me "AD is a great choice! , you can use it everywhere", so If anyone has got any experience /feedback to give me on this, it would be really helpful.
Also: How should rights/roles be managed ? Should all access/rights/roles for each application be stored in AD, or should this be stored in the applications themselves.
IE : AD stores the roles:
"Cms" <-allowed to login to the cms system
"Cms.Article.AddAllowed" <-allowed to add article
"Cms.Article.DeleteAllowed" <-allowed to delete article
Or should this information be split up, so that AD holds information about which applications the user is allowed to log into, while the application itself holds information about what the user is allowed to do within the application when logged in
AD rights:
"Cms" <-Allowed to login to the cms system
Cms rights:
"Article.AddAllowed" <-allowed to add article
"Article.DeleteAllowed" <-allowed to delete article
So, when the user logs in, they are first authenticated against AD, and if that goes ok, the rights for the Cms application is fetched from a rights-table in the cms system ?
What are my options ? What other solutions other than AD do I have ?
Thank you for any feedback, its much appreciated !
We have done something similar in my organization. Here is the overall flow:
User requests web page
User is redirect to login screen along with SAML request
User authenticates against Active Directory
User is passed back to request web page with SAML response
User group/rights information is retrieved from database
If user requests page from another website same process occurs however if the user still has a session or selected the "remember me" feature then user does not have authenticate and gets logged in directly.
We use Sharepoint, but have not setup SSO yet. I believe Sharepoint gets the rights of the user from its own backend database/system. We also have a homegrown system to update user's groups/rights. I know Sharepoint can use web services so you could possible update Sharepoint when using a centralized user management system (of course you'd have to build that). The main thing is finding out where Sharepoint gets its information about the user and how you can tie your existing system to it...
I wouldn't rely on Active Directory to store group/rights information. It a pain to deal with compared to a database and is not flexible. It's fine for authentication and password management you just have to tie the user on Active Directory to your database system.
As far as I know, Active Directory is only practical for users within your domain. You would need an administrator to manage all those users and to add new users.
I've been working on a project myself where I wanted users to sign in, just to know their identity. I did not even care about their access rights but just wanted an identity on every visitor, something more reliable than an IP address, cookie, session key or whatever else. So I first asked my administrators if I could use Active Directory for this project. Sure, I could. But the webhost wasn't connected to our company domain so I would end up with only one user. Yeah, my administrator is a bit sarcastic sometimes.
So I started to explore SSO options. OpenID like this site is a good option and you could even implement your own OpenID server and require all visitors to sign on there first. It's a very powerful technique and you have less worries about managing users in your project. (Because the OpenID provider takes care of this.)
However, I ended up using CardSpace instead. :-) With CardSpace, every user can create their own user-token and store it on their own system. To log on, the website just asks for the card and the user just clicks on it. Those cards can be migrated to other systems but tend to be tied to a single computer and user, most of the time. (Although users can share a card!)
Rights and Roles are a different matter than Authentication. People always think they're connected while in reality, these are two different things. First, use OpenID or CardSpace or another authentication technique to verify the identity of the user. It doesn't matter how they're identified, you just need an identifier.
Next, you need rights and roles. Roles are basically just user-groups and you can connect an identity to a group. Or to multiple groups. And rights would be linked to roles, not users. But how you're going to divide these roles just depends on the applications. Just remember that someone who is an administrator in your version control system should not be an administrator in your customer database. Roles tend to be application-defined, thus every application could manage their own rights and roles and just needs a way to link these to an identity.
I myself just needed identities so I knew whom to blame when something ended up messed up. Then again, when there's only 5 users, things tend to become quite simple.
First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.