Overview
Our SharePoint 2010 application will be launched from a 3rd party application, let's call it HealthApp, via an embedded URL. Much of the time the user will be logged into HealthApp from a shared workstation. As a result, SharePoint will not sign in automatically using the Active Directory credentials.
Requirements
We need single sign-on.
We need to continue to use Active Directory as the STS for various reasons.
Authentication from a stand-alone browser on the user's workstation will need to work as it does now.
Authentication Info
HealthApp can pass a username and any other custom identifier information we want as URL parameters.
The username will match the users Active Directory username.
We will not have a password.
We need some way to authenticate the user based only on the username/identifier.
Possible Solutions
Is there any way to bypass the password check in Active Directory?
This would appear to be the simplest solution if possible.
Can we
extend the Active Directory provider to authenticate using a generic
user and then log into SharePoint with the username passed on the
URL?
Any other suggestions?
I would think there would have to be some way to do this but have not had much experience with claims based authentication with SharePoint.
Thanks for any insight.
Me also facing same issue for authenticating users over share point site that uses claims authentication.As per requirements my app needs to access share point data. So to authenticate
over share point server from an app we need to provide some authenticated claims with the request so that share point STS can issue an authorization ticket to access the share point site resources. after spending more than 2 days in googling i found some interested article that may help to authenticate users from client app against identity provider systems.
OAuth library
this resides between app and identity provider system. using this you get an authenticated claims that will further use to authorize over share point server with the help of Share point STS.
Related
We have several websites that use same authentication method. The account and authentication is via a third party system and we developed library to authenticate against in C#. The user would enter a user & password and C# library will pick it up and do the authentication.
Following is what we are asked to implement
A user logs into any one of the sites. At that time a token needs to be created it should be good for a period of time.
If the same user tries to access another of our site, user should automatically log in because there is an unexpired token from step 1.
Is there a way to implement this? From what I know all the cookie and storage are per site and one site's cookie cannot be accessed by another one. If one site can access another ones token that is a security breach to me. So is there anyway to achieve this?
I'm developing an application where Google Drive will be used to manage some documents. The idea is to create a document with some initial template data and provide the users access by adding them as collaborators of the document.
I'm familiar with the OAuth authentication process, I used it in another part of the system to manage the users Calendar...
But in this case these documents will be stored in a generic account of the company, so I can't have the approval prompt for authentication, since users won't have the password of the account.
I'd like to directly authenticate in this account, could be with the username and password hardcoded in the Java code.
Problem that this method of authentication was depreacated and I didn't found a relpacement.
Any ideas?
Thanks in advance,
Phillip
There are 2 ways that comes to mind:
Service accounts: best suited for server side OAuth with traditional backend
Regular Account owned by the application : similar to the process already in place for client side Oauth that you are already familiar with; Auth, store the refresh, ask new token if the AuthCode is expired, and so on.
I personally use and prefer the second solution more as I feel is more flexible to adapt in the future for Oauth Client Side get the tokens and use them server side.
Good evening, I must make an intranet with Liferay, the most important is to integrate a web application (or 2) already ready with the portal that I will make . These web applications are made in php, so in order not to make each authentication, wanted the user to authenticate to the portal and click on the link to one of these web applications, it will not have to authenticate again for its apps. For this reason I used SSO CAS and I integrated it with Liferay, I still used an LDAP directory to be related to the CAS server to identify users.
My problem is how is the procedure for other web apps, is that users must have the same login and password for partail (Liferay) with the others two apps php? Or I can let each application with their users without the change (because in each app, the user has a login and password different from other apps), that is how the coordination between different words and LGIN passes the various apps (this is a problem of SSO, I misunderstood the principle of work I should implement it) ??
Some clarifications and assistance please??
The other webapps need to implement a so called CAS Client. The php one is here:
The php apps will typically redirect non authenticated users to CAS, and after they logged in the webapp retreive a saml token. In that token claims are found that uniquely identify the user. application then typically match the provided claim to their own userstore or apply the concept of a virtual user.
But that is up to the implementer of the webapps.
I am writing a WPF application, and one feature I want to implement is the ability to display a list of computers in the domain. I have found some useful Active Directory code here:
http://www.codeproject.com/Articles/90142/Everything-in-Active-Directory-via-Csharp-NET-3-5-.aspx
Typically code examples dealing with AD seem to require the user's credentials to make requests. But it occurs to me that if you are running the application from a computer that is part of the domain, the user has already provided user credentials sufficient to access AD on that domain controller, when logging on to the system.
Is there some way that the user can access AD via my application without the app having to ask the user to reenter the same credentials again? I mean is there some kind of token that I can forward that indicates the user is already authenticated? I am concerned about the risks of having to store and transmit credentials securely when I don't have to.
Thanks for any advice.
I later discovered that if you are logged on to the domain, that is sufficient for you to access the active directory store, without having to supply further credentials or impersonate an admin. And in some cases you can also access it without being logged in at all.
So a bit of background, I'm working on an existing web application which has a set of users, who are able to log in via a traditional login screen with a user name and password, etc.
Recently we've managed to score a client (who have their own Intranet site), who are wanting to be able to have their users log into their Intranet site, and then have their users click a link on their Intranet which redirects to our application and logs them into it automatically.
I've had two suggestions on how to implement this so far:
Create a URL which takes 2 parameters (which are "username" and "password") and have the Intranet site pass those parameters to us (our connection is via SSL/TLS so it's all encrypted). This would work fine, but it seems a little "hacky", and also means that the logins and passwords have to be the same on both systems (and having to write some kind of web service which can update the passwords for users - which also seems a bit insecure)
Provide a token to the Intranet, so when the client clicks on a link on the Intranet, it sends the token to us, along with the user name (and no password) which means they're authenticated. Again, this sounds a bit hacky as isn't that essentially the same as providing everyone with the same password to log in?
So to summarise, I'm after the following things:
A way for the users who are already authenticated on the Intranet to log into our system without too much messing around, and without using an external system to authenticate, i.e. LDAP / Kerberos
Something which isn't too specific to this client, and can easily be implemented by other Intranets to log in
Both of your suggested options are insecure, even if you use SSL. Never pass credentials on a URL, put them in the HTTP request by using POST.
There is a standard called SAML and this can be used to solve your problem. The challenge is choosing which version to implement. I would choose SAML 2.0.
Google Apps implements a flavor of SAML 2.0 and allow you to authenticate using your intranet credentials. In the case of your application, you would be the service provider and your client would be the identity provider. As long as you implement the standard correctly you should be able to support any new client (identity provider). Here is a list of SAML implementations you might want to take a look at. If you need the client to pass over information in addition to the authentication information then SAML can facilitate this with metadata.
You will still need to implement SSL to encrypt network traffic.
I hate to answer my own question, but I hate even more a question with no answer. In the end we went with a very similar implementation of SalesForce's delegated authentication SSO implementation.
http://wiki.developerforce.com/page/How_to_Implement_Single_Sign-On_with_Force.com
Essentially the solution has a trusted site, known as the delegated authentication authority, who has a list of users who are logged into the company intranet.
When the user logs into the company intranet, and they click a link to our application, the company intranet will pass the user name and a generated token (which expires after a set amount of time) to our application.
Our application will then check if the user name is on our site, and if so, send the username / token (along with the source IP and a few other parameters) to the delegated authentication authority. If all those items match on the delegated authentication authority, it returns true and the user can log in. If it returns false the user is denied access.
We've found this system to work quite well, and even implemented a couple of extra security features like SSL, client side certificates, VPN tunnel, and even restricting the IP addresses which can access the site and the delegated authentication authority.
I know it's bad form to answer your own question but I hope this helps someone else who might be having the same problem ...