One of my requirements is to implement single sign-on for a set of sites. There is no need to support Open ID as usual nor become Open ID provider. However, I think about using Open ID internally. My questions are:
If my Open ID provider is limited to a trusted list of domains authentication experience will be transparent to users (except few redirects to the provider sub domain and back and bit different forms design)?
Since the provider is not public (a list of domains to check redirects against) there will be no new attack surface introduced?
If one of the sites has a desktop application should the application talk to the provider directly or via a facade of the site?
Found similar question which is useful but does not really answers mine.
1) Yes, the experience can be similar, but not seamless. For example, you might not be able to have username/password login box on the site.
2) The provider has to be accessible by the client (not just Relaying Party). So it depends on whether your clients are internal or internet.
3) It really depends on whether the application can do OpenID. Also, see (1), can the application handle opening up of the provider webpage?
Related
I'm looking for a bit of best-practice advice from someone a bit more knowledgeable than me in the Federated Security area.
Our Scenario
We host a (subscription) webservice (WCF/Asp.Net/IIS). We also have a purely JavaScript component (widget) that our customers embed within their intranet applications. The widget calls the webservices for data so therefore we need the widget to make cross-domain requests from their domain to our domain.
The widget currently does this using a combination of JsonP and Script Tag Injection approach to Ajax. (Reason - a combination of the age of the widget and continuing support for older non-CORS browsers).
The Problem
All of our customers require a Single-SignOn so their users are not asked to login to the widget. We have achieved this in until now by issuing an ApiKey to a new user and asking them to enter that into the widget on first use, and a cookie is then created for use thereafter.
We need to integrate Federated Authentication into this scenario. The webservice (on our domain) is the Relying Party (RP) and the widget (hosted on the customer domain) is the Client. The Identity Provider and STS would also be on the customer domain.
From my research so far I think I can make the following statements:
This scenario requires an Active Federation approach. Passive Federation is never used when the RP is a webservice.
We need to add Federated endpoints to our WCF service to allow an Active client to call us supplying a Saml token.
Making our widget an Active client that communicates with the webservie directly is not possible. This would require the Widget to request identity and pass it onto the RP. This would be too much for a JavaScript only app.
Possible Solutions
Is it actually up to the host page of the widget (aka. the customer's intranet application) to be the Client in the FedAuth scenario?
We could provide a proxy that would be hosted in the customer domain and act as the Active Client for our webservices RP. The widget could then be unaware of any authentication.
Are we missing something really obvious?
I would really appreciate a couple of words in comment on the above if you can help us out and can spare the time. I'd be happy to hear that my assertions are incorrect as well. All news is good news at this point...
We eventually found a workaround:
For customers who want Saml Authentication we host the widget component in our domain in a standalone webpage and they embed in their webpage using an iframe.
this approach achieves the appearance of widget integration within their site, although not as originally intended, and it allows us to leverage Passive authentication. The iframe behaves just like a normal browser in that respect and handles the handshake with the STS server.
This is less than ideal but we were unable to come up with anything better. It suits our customer's needs whilst maintaining security. That doesn't mean I have to like it though.
There are plenty of questions here where someone wants to load an OpenID provider's login page in an iframe rather than redirecting and having the provider control the entire look & feel of the login page. For very solid security reasons (primarily anti-phishing) this is a big no-no, prohibited, and most OpenID providers refuse to load within an iframe.
I have been presented with a situation where OpenID is being used within a single organization's set of web sites and applications. The OpenID provider has a whitelist of RPs and will only respond to those RPs. There is a desire to extensively customize the login page at the provider based on which RP sent the user to it. (If there are strong security arguments against doing this as well, I'd like to know about them as well.)
A proposed solution to this is to simply allow the RPs to present the login page in an iframe, so they can put whatever design around the login box they want. In this scenario only the "Username" "Password" fields and "Login" "Forgot Password" "Register New Account" buttons would be hosted at the Provider, the rest of the page would be at the RP and still have the RP's address in the title bar. Not optimal, yes, but the argument is that "it's a different subdomain, but the same 2nd level domain, so it's still okay."
I don't understand how this could be the case - having very different login pages for different applications still leaves users more vurnerable to phishing and other attacks. Am I incorrect in this conclusion? Every question on SO about this appears to be about using an external or public Provider, and the counterargument I'm encountering is that those concerns don't apply in a private Provider limited to sites on the same domain.
The general concerns about having OpenID within an iframe do have some validity even if you role your own provider. If any of your components are vulnerable to script injections there's a risk that they could compromise your users credentials since you could access iframe data from the parent window.
The normal recommendation to redirect (optionally in a pop-up) would limit this risk since the attacker now need to inject into the OpenID login page where you presumable have no script injections flaws.
Two years further on and I do not think that this is currently considered to be a bad idea, specifically because there is an OpenId Connect specification (currently at draft 21) which is detailing the process by which an iframe should be used to enable a RP to communicate with an OP in an iframe.
http://openid.net/specs/openid-connect-session-1_0.html
I don't know how long it is until this becomes ratified, but it does show that this is under consideration as a valid approach for managing sessions in a RP.
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.
I need to work out a way to setup the validation of the users of a web application before they've actually arrived at the site. That is, someone browses to a url, enters a username and password which is then validated against a db or whatever. They are then automatically redirected to the real web application, on a different domain out across the internet, which is passed the details of the user and which then lets them through to the site without asking for the credentials again. And this must be done as securely as possible.
What are the options available for this sort of problem?
Thanks,
What you are describing is a typical use case of intern-domain web authentication. There are multiple ways to do it,
If both domains belong to the same application/company, you can just do your authentication and then pass some token/secret to the other domain in your redirect. The other domain can drop another cookie to maintain the session. This is practically how it's done between different domains all popular websites. For example, flickr.com uses yahoo.com to login.
You can use Identity Federation if the domains are closely related (partners). Most popular mechanism to achieve this is through SAML.
OpenID can also be used (That's how you arrived at this site) if the sites are loosely connected. OpenID uses arcane login URL so it only makes sense for tech-savvy users. The regular user may easily get confused by its complicated login process and consent page.
OAuth is an authorization scheme. It's not designed for federated login but you might be able to use it.
Look up OAuth or OpenID.
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).