Looking for a pointer in the right direction ...
Is there a mechanism which allows you to configure SharePoint in such a way that:
if a user has been successfully authenticated within a SharePoint site that there is some kind of "authentication token" what can be passed or is available to 3rd party sites
or a way for 3rd party sites to "recognize" that the user is currently authenticated within a sharepoint environment
all 3rd party apps can be modified to accommodate whatever needs to be done
but the constraint is: SharePoint may or may not be a hosted (by a separate service provider) and how the original authentication took place is irrelevant i.e. just need to know they authenticated ok, not how
EDIT
scenario to help clarify:
authenticated SP users require access to a 3rd party service provider for additional content. a "link" on their SP site redirects through to the 3rd party. the 3rd party needs to recognize the referrer (based on a collection of evidence supplied by the request) so that it need not challenge for a secondary authentication process.
one of the 3rd parties is me. the SP instances are many and varied and would be any one of my clients (which i don't offer support to, just provide a content service to).
so the attempt is to solve more of a general "community/ecosystem" problem.
Going on the small amount of information available here.... You are probably going to use Windows Authentication (via Active Directory) or Forms based authentication.
If you are using AD within your organization and the other server you are authenticating to is using the same AD, it's a no brainer. If it's AD based but both servers are using different domains, it's much more complex. One option would be to setup a trusted share between the ADs.
If you are using Forms Based authentication it becomes a bit more of an issue. If both servers are using the same FBA, you could create the authentication cookie in SharePoint and then add the cookie as a header to a Request object and then redirect to the server.
If they are different authentication methods totally, you need to determine if your security requirements will allow users to authenticate via some URL based mechanism (like querystrings) and then develop the logic on your SP box to create the URL to authentication.
Your requirements are a little vuage but this should point you in the right direction.
Plan authentication methods (SharePoint Server 2010)
Specifically Claims based authentication.
I'm guessing that by "3rd party sites" you mean sites that aren't hosted in your domain. If that's the case, then the servers won't be able to use your AD authentication (unless you share them, which probably isn't worth it).
I would suggest modifying the way users are authenticated on the 3rd party servers, as you have control over how you send your users over there. You could easily encrypt their usernames/emails/unique IDs and a timestamp (to make sure they can't bookmark that link) in a query string.
The information is then decrypted on the 3rd party server. Invalid information and they are redirected to your login page. Valid information and the 3rd knows that they were authenticated in your sharepoint app.
Your question is very confusing.
SharePoint may or may not be a hosted
What do you mean by that?
Are you invoking a 3rd party web app from a SharePoint page? You can get the current user using SPWeb.CurrentUser property and make use of it.
Related
As with many applications, my service's authentication logic lives in the application code. Now however, I need to expand my authentication to incorporate 3rd party identity providers for single sign on.
I want to retain the old authentication behavior (database lookup) but also want to add support for 3rd party identity providers.
With this increase in complexity, does it make sense to separate the authentication logic to its own service? In this model the application server will redirect unauthenticated users to the authentication server. After authentication is successful, the authentication server will redirect back to the application server.
Is this approach sound?
If you have available servers and infrastructure budget, let your web application perform the authentication, using a community maintained library.
Generally its no recommended to build one by yourself.
Store your users in a database table.
Authentication using other sites problems:
Your visitor may not want to have an account with 3rd party site.
It results in giving too much information to the 3rd party site (who share much of it with other sites which use their authentication mechanism).
It is generally a good idea to separate your authentication logic and have a different service perform that task. This is also true for other 'cross cutting' concerns such as authorization and SSL offloading. It gives you a simpler development environment and in general an app that is easier to reason about (for example, you don't have to worry about authentication while in development mode and you can develop the services independently which goes a long way in terms of productivity and velocity).
In order to compose the authentication service with your application, it is better to have a third component that orchestrates and routes the calls accordingly (as opposed to having autentication related code in your application).
I have the following scenario:
1.- A web api project in Azure, that I want to secure using Azure AD (I don't mind Token, cookie, whatever, as far as it meets the entire scenario)
2.- An Azure web site in asp.net MVC, also secured by Azure AD. This website has to call the web api controller with SSO (I'm using same Azure AD in the entire scenario)
3.- Some JavaScript code running in a page in SharePoint Online, also calling the web api controller in any secure way (The Office 365 tenant is also using same Azure AD). If you don't know about SharePoint, let's say I have an SPA project where I can only use Javascript and html (no server side code).
Following some of the MS Azure AD samples and some blogs from Vittorio Bertocci I'm able to get the points 1 and 2 working fine, using OWIN and Oppen ID connect. However, seems impossible to achieve point 3. As I'm inside a page in SharePoint Online, I can only use javascript, and not any server side code. I'd like to get a valid token for the current user, that is already logged in SP, and remember that SP uses same Azure AD that web api site.
Can I call the Azure AD and get a valid token, just from client code?
I'm open to any possible solution. I can do whatever in the web api project. If you are thinking in a SharePoint app with an appPart, and the appPart calls the web api from server side code, I agree that will work, but it's an option that is not allowed at the moment :(
Many thanks.
I have similar needs. While waiting for a Microsoft sponsored solution we’re working on the following approach.
3) in Your solution (i.e. HTML page with JavaScript, hosted in SharePoint Online and running in Browser) will call Services in 1) (i.e. Web Api Service layer in Azure).
In Our case we only want to validate that the calls made from SharePoint Online (via users browser, i.e. JavaScript) originate from a correct Office 365 / SharePoint Online user in our tenant.
We are opting out of using the App Model as we only want some simple HTML / JavaScript pages in our Intranet and don’t want App Webs. The Web Api server side code is kind of our “Web Part” code behind.
Change to the solution after trying it out and having workable code:
The auth cookies are ReadOnly and cannot be used. Instead we have registered one metod in our service layer as App in SharePoint Online (via appregnew.aspx). That methods url (e.g. https://cloudservice.customer.com/api/authentication/token) is registered as App start page in the app manifest and is deployed to a site Collection.
Now we can call our App via https://customer.sharepoint.com/sites/devassets/_layouts/15/appredirect.aspx?instance_id={GUID} i a jQuery ajax call and parse the result. AppRedirect sends the correct SPAuthToken which we use in our service endpoint (i.e. App start page) to call back to SharePoint and check context.Web.CurrentUser. User email is then stored in Table Storage with a generated Token which we send back to the caller (i.e. the jQuery ajax call to app redirect).
That token is then used in all other service layer calls in order to be sure of who is calling our service layer and in some cases perform authorization in our service layer.
Note, You can use the same approach in order to store Refresh and AccessToken in your client and provide that in all calls to your service from your client and use those tokens in order to do App Calls back to SharePoint. This enables HTML UI in SharePoint host webs and server code using user context in Azure service layer.
To follow up, ADAL.js has recently been released, and the ability to use CORS with O365 APIs was recently added, enabling a scenario for script clients to communicate with services protected by Azure AD, such as your Web API.
http://www.andrewconnell.com/blog/adal-js-cors-with-o365-apis-files-sharepoint
UPDATE 2018:
This is now supported by SharePoint Online and the SPFx development model, and officially documented, for instance here
Consume enterprise APIs secured with Azure AD in SharePoint Framework
Being said that the work done meanwhile by Vittorio, Kirk, and their teams, but extending that also to Andrew that has delivered great samples, is awesome; that doesn't really fully reply the original question because one of the requirements is to don't run the component as Add-in Part.
If you try to use ADAL JS (which starts its own OAuth flow) hosting that directly in a SP page, that's not going to work, or anyway you can expect a weird behavior for the user (cause of client redirects happening on the browser).
The solution proposed by Peter Karpinski is interesting, and will work matching the requirements in the original question, but requires quite some complexity and additional management/resources.
This recent article provides an alternative solution similar to Peter's one, but requiring less 'extras' and somewhat simpler, also reusing user's SP identity.
Consuming Azure Hosted Web API from SharePoint Online using JavaScript and Office 365 identities
and doesn't either require the use of ADAL on the client side and the implementation of custom security provider / token issuer on the server side.
The identity (cookie) will be passed via properly handling CORS (documentation) on both sides.
However, as you can read in my comments to that blog, this won't work normally with IE due to its security zone implementation. You'll have to be sure you have control on IE security zones on the clients, or have an alternative solution specific for IE.
As of today AAD does not support the OAuth2 implicit flow (or OpenId Connect variants) hence you can't obtain a token from AAD using a user-agent (browser), regardless of whether you hit the wire handcrafting the protocol or using a library.
However keep an eye on future announcements, as this is an important scenario for us!
HTH
Cheers,
V.
update we now support the implicit flow on our server, and we released a library for helping you consume the new feature: http://www.cloudidentity.com/blog/2015/02/19/introducing-adal-js-v1/
Thank youi for r your patience!
The fact that you say you can use only HTML/JS let me guess you're having a SharePoint-hosted App.
Azure AD Authentication Library (ADAL) doesn't provide yet in this moment support for HTML5.
I've been looking since a while (almost one year) on how to implement something as you say; but I couldn't find any working solution, which doesn't make use also of some 'code-behind'.
I'd suggest you then to move to a Provider-hosted App, where you'll be able to have some C# code, and make use of ADAL to retrieve and reuse the OAuth token.
Also, I think is worth to look at this documentation page:
Choose patterns for developing and hosting your app for SharePoint
at section Match your hosting pattern with your development goals
thanks for your help.
Well, it's not a SP-Hosted App, but it's same scenario. It's just a SP page in SP Online, so I can only use JS code like in a SP-hosted app.
As I said in my question, I agree the Provider hosted app is likely the right (or at least, the unique) solution, but that means to build and app, deploy it, and add teh appPart manually to the page (is not easy to package in a WSP). So, this solution is quite hard, when you only want to make some AJAX calls and show some data.
However, after all that I've seen, I think we can't do anything else. I'm gonna wait some more days to see if someone know any weird workarround that could work, and if not, I'll mark your answer as valid.
Thanks again!
So I've read numerous articles on a password system for a web app, and they all seem very confusing. Some say you need to hash your PW's AND establish an https secure connection, others say you just need to hash AND salt your PW's.
I just know, after this has been done millions of times, there's PROBABLY some sort of library out there that can do a bunch of things for me for a password inputted on a client side, and give me something to save securely in my SQL Server 2008 database.
Do I need to worry about all the https secure connection stuff? Can I just make sure I hash the PW correctly? To hash it, do I need any external libraries or can I create a secure user/pw system entirely in .NET?
I've never done this before so any articles, tips, links would be very helpful. Thanks.
If you don't want to roll your own you can always use ASP.Net Membership
ASP.NET membership gives you a built-in way to validate and store user credentials. ASP.NET membership therefore helps you manage user authentication in your Web sites. You can use ASP.NET membership with ASP.NET forms authentication by using with the ASP.NET login controls to create a complete system for authenticating users.
ASP.NET membership supports facilities for:
Creating new users and passwords.
Storing membership information (user names, passwords, and supporting data) in Microsoft SQL Server, Active Directory, or an alternative data store.
Authenticating users who visit your site. You can authenticate users programmatically, or you can use the ASP.NET login controls to create a complete authentication system that requires little or no code.
Managing passwords, which includes creating, changing, and resetting them . Depending on membership options you choose, the membership system can also provide an automated password-reset system that takes a user-supplied question and response.
Exposing a unique identification for authenticated users that you can use in your own applications and that also integrates with the ASP.NET personalization and role-management (authorization) systems.
Specifying a custom membership provider, which allows you to substitute your own code to manage membership and maintain membership data in a custom data store
Configuring an ASP.NET Application to Use Membership
There's also a project on github called Membership Starter Kit for MVC
The default MVC3 Internet Application template (file-new project) has this setup for you already, simply add [Authorize()] to the controllers/methods you want to protect. Don't roll something new, use what's there for you. In addition, please use SSL as someone can easily steal a session by sniffing traffic and simply using your cookie. It's that easy.
We are developing a Intranet portal that uses integrated authentication, but a few sections of the site will be exposed to users who are not in the domain. For those users we plan to use anonymous access. However, our display logic for the entire application is based on the user logged into the portal, so we are not fully comfortable with this approach. The URL has to be same for both types of users and transitioning between both the environments has to be seamless.
We tried using user controls in pages to authenticate but things didnt pan out. When the page is reached the standard windows authentication grey box pops up.
Is there any way to intercept the request at the IIS level like an HTTP application?
If applicable we would disable anonymous access and for unauthenticated users we will impersonate with a least privileged domain account and redirect to the home page.
SharePoint isn't really designed for the scenario you describe of mixing types of authentication. It dedicates a web application to one type of authentication. You can then 'extend' that web application to use another type of authentication on another address. For example, your intranet portal would use Windows authentication. It could then be extended to use anonymous authentication on another port or domain name.
One option for what you describe is to configure two separate web applications. One is for users that need to authenticate. The other is for anonymous access. Configure the content in the appropriate locations and link between the two as necessary. Users within your domain should not receive a login prompt when connecting to the authenticated site if you use this approach. Users outside your domain will receive a login box and won't be able to access.
Consider using forms authentication for users outside your domain if they need to access your intranet. (Once again the 'forms authenticated' part of your site would be extended to a unique domain name or port.) This would mean they will be prompted to enter their credentials in a form on the page when first connecting.
Read more about authentication on the Authentication Resource Center.
A couple of final points... If you can use SharePoint's default authentication mechanisms rather than writing your own controls, use them as they are well tested and secure. Also, don't be tempted to change SharePoint's IIS settings unless you are certain there is no other way to do what you need. SharePoint regularly updates these itself and may overwrite your changes (or give you grief in other ways).
We have one web application (sharepoint) that collects information from disparate sources. We would like to be able to link users to the main websites of those various sources and have them pre-authenticated. I.E. they enter their credentials for the other sources (which are a number of different types LDAP, AD and home grown!) and we retrieve some information for them, and remember there details (Possibly Single Sign-on to keep em nice and safe). The user can then click a link that will open the full app in another window already authenticated.
Is this even likely to be possible?
Office Server has a Single-Sign-On api as a builtin feature. you may want to look into that. It enables you to register user credentials securely, and to access it at runtime.
You need to act as a web browser acts to different sites with storing credentials (usually in cookies) locally. Use therefore a a proper client library with cookie support. This could go probably for most of sites. There are sites using HTTP authentication, which are also easier to access from appropriate client libraries. The most demanding can be access to SSL websites, but again, most client HTTP libraries cover that nowadays as well.
All you need now is just to prepare your web application to act as a proxy to all those separate web resources. How exactly this is done in Sharepoint, well, I hope others will answer that...
True Single Sign-on is a big task. Wikipedia describes common methods and links to a few SSO projects.
If you want something lighter, I've used this approach in the past:
Create a table to store temporary security tokens somewhere that all apps can access.
From the source app (Sharepoint in your case), on request of an external app, save a security token (maybe a guid, tight expiration, and userid) in the token table.
Redirect to a request broker page/handler in the destination app. Include the final page requested and the guid in the request.
In the broker, look up the security token. If it exists and hasn't expired, authenticate, authorize, and redirect to the final page if everything is good. If not, send a permissions err.
Security-wise, a guid should be near impossible to guess. You can shrink risk by letting the tokens expire very quickly - it shouldn't take more than a few seconds to call the broker.
If the destination app uses Windows Auth and doesn't have role-based logic, you shouldn't have to do much. Just redirect and let your File/UrlAuthorization handle it. You can handle role-based permissions with the security token db if required.