I am just getting into Sharepoint, and I have a question about having a Sharepoint internet site, and a Sharepoint intranet site.
Is it possible to have an internet site, and have a login type function, that when the user logs in, they are taken to a site like the Team Site? I think I'm trying to integrate an internet/public site with the Sharepoint functions that users are familiar with in an intranet site.
My goal is to have non-private info on the internet, but once authenticated, the user would be able to upload docs, search docs, see a calendar, that sort of stuff.
Maybe I am not totally clear due to my lack of understanding thus far of Sharepoint?
The google keyword here is Forms based authentication.
Here is a good post to start you off and a second including Mysite setup
Related
I have two sites, one of which is essentially embedded into the other, although they have to be loaded from different URLs. They both access the same backend API. I want the user to log in once and be able to access the API in the embedded site without having to log in again. Essentially, I guess this would be Web-SSO. To complicate things even further, the outer site is a legacy PHP site with a backend server, the inner is a single-page react app.
I'm looking for a way to pass the login from the outer site to the inner site, without actually passing a login token around e.g. as an URL parameter, which would probably not be safe.
Essentially what I'm looking for is something Site A can safely give to site B, that will tell the authrisation server "Site A is authorized, and Site A trusts Site B, so it's OK to give Site B a token too"
Does such a mechanism exist? Some people have suggested OAuth2 and OpenID to me, but in all the documentation I've read, I haven't found any description of this use case. To me, this looks like OAuth2 in reverse. All examples I have seen concern the use case "Site A wants to access Service X, so it needs to authenticate with the Auth server Y, to get a token that will let it access the service". A second site wasn't part of the picture in any of the examples I could find.
Is OAuth2 even the right technology for this, or do I need something else entirely? How does one implement this use case?
If I understand correctly, you just want/need SSO. Since if a user logged in in site A (or any *.domain.com or *.com that is registered as a "safe" application) it will also be logged into site B.
Essentially how this works is when the user is logged in there will be a cookie stored on this website and (not sure) also on the API login website. Then whenever the user tries to enter website B e.g. the application should check for a cookie on site B. If there isn't any cookie it will look for a cookie on the API login website. If there is it will automatically login (without credentials). This is basicly what you say.
Site A can safely give to site B, that will tell the authrisation
server "Site A is authorized, and Site A trusts Site B, so it's OK to
give Site B a token too"
This could be achieved by using a third party like Auth0. Im currently trying to implement this in Symfony. So far not much success but since I searched alot for other SSO providers I think this is the best shot. Also for your needs I belive it will work good enough.
Another option:
Create a API authentication server yourself. This way you have full control over it. But you need to manage it all yourself, also the security. There are probably packages that help you alot but still, you need to figure out alot by yourself.
My advice is to check out Auth0 by just creating a free account. See what it can offer and try some things out.
More specifically, I mean being able to provide an OAuth2 service.
I've seen multiple websites used "Sign in with Twitter" "Sign in with Google" etc.. on their websites. I'm wondering if there's a certain process you need to go through in order to allow other websites to use your websites to authenticate.
Let's say I've got a website called "SomeRandomSite", and people can sign up/sign into this site as they normally would, but then if you go to some other website you'd see a "Sign in using SomeRandomSite".
When looking into it, I came across this article here:
http://scottksmith.com/blog/2014/07/02/beer-locker-building-a-restful-api-with-node-oauth2-server/
I have yet to finish reading all of it, but so far it seems like it's only allowing your application to incorporate other OAuth services such as Google, rather than building your own.
I hope I explained this well enough haha.
Implement OpenID Connect if you want to make your server behave as an Identity Provider (IdP). You can find a list of implementations of OpenID Connect in "Libraries, Products and Tools" page.
It basically means you want to act as an IdentityProvider, take a look at ThinkTecture.
https://identityserver.github.io/Documentation/
It's cetainly possible, but an Identity provider is usually a well known(trusted) party, between the IdentityProvider and the target site the user want's to log into there should be a trusted relationship, in other words the target site should register with you the IdentityProvider
Getting started example
https://identityserver.github.io/Documentation/docsv2/overview/simplestOAuth.html
we are trying to implement single sign on, across multiple domains, but using the same web application under IIS. We have checked some solutions like SAML and OAuth however we are not sure we need anyone of these two. We dont know how we could share the cookie accross the domains, I dont think it's possible but correct me if I'm wrong.
We have looked at google's solution when you go to youtube and you are authenticated with your google account it pulls out your username and your info, but we have no idea how they do this, because it's another domain so the cookie should not travel to youtube. If you have any suggestions on how to do this they more than welcome.
You may take a look at the following blog post in which Jeff Atwood explains the mechanism used by the StackExchange network to support cross domain single-sign-on relying on HTML5 Local Storage. And here are some more technical details.
I've been asked if it's possible to create an ASP.NET MVC website which integrates a phpbb forum in an iframe, and lets users login and register to the forum through the website, as well as making them logged in to the entire website at the same time.
Is there a good way to make this possible efficiently and securely?
I've no experience with phpbb or php.
There is no API you have to build it all yourself. There are several strategies you can follow, one secure way is to let the other application integrate via the database and let it use the same session information (user, session, key tables).
Please see also this question:
Replicate PHPBB password hashing in ASP.net c#
I'm designing a new web application. Some quick points on it:
ASP.NET MVC Web Application
SQL Server 2008
Entity Framework ORM
3 User Roles: Anonymous, Registered, Administrators.
Anonymous users can view stuff, Registered Users can post stuff, Admins can do anything
Heavy social integration with Facebook, Twitter and the like.
I plan to use OpenId for authentication (DotNetOpenAuth)
So, pretty simple right? (famous last words)
Now my question is:
Should i provide OpenId as the only means of authentication, or should i
also give the user the option to log
in using my own authentication system?
So this is basically a "User Experience" question. Take the example of StackOverflow - you MUST signup with OpenId. It seemed fine to me, but what about the general public? Can i be happy with the fact that a user of my site must have an OpenId account? (or signup for one before using my site)
Is giving the user two options to login bad UX?
I realize this is a partially subjective question, but im just looking for advice on which road to take, some case studies would be helpful.
Thanks.
Any good answer to a subjective question begins with it depends. :-)
I think if your prospective user base is already fairly social-network engaged (as it sounds by your description), it will probably be just fine to have authentication handled by OpenId providers. The important part is providing an easy-to-use login process, and make it obvious that various providers are available for authentication (Yahoo, Google, etc.).
If your prospective user base is going to consist of new or inexperienced Internet users, even a simple OpenId implementation may be too confusing.
I, for one, find it annoying to have to create yet another account every time a visit a new website, and I suspect that more and more users are feeling the same way.
There's a decent set of responses to a similar question at https://ux.stackexchange.com/questions/78
The thing is that only OpenID won't cut it in you case mainly because of Facebook and Twitter who aren't OpenID providers. Both use OAuth 2 for authetication. Wikipedia says this about it:
OAuth (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.
and this:
OAuth is a service that is complementary to, but distinct from, OpenID.
The DotNetOpenAuth also supports OAuth and the latest CTP release implements the OAuth 2 draft 10. Mind you that the OAuth 2 specification is still being developed and is expected to be finalized by the end of 2010. OAuth 2 also isn't backward compatible with OAuth 1.