Once a user has been authenticated via Orchard CMS is a cookie set on the users's system? If so can I read it from the same domain?
I would like to use Orchard to authenticate a user before re-directing them to another location on our domain and I am trying to determine how the web app they are redirected to can determine if they have been authenticated before allowing them access.
Orchard uses ASP.NET Forms Authentication mechanism so yes, there is such cookie set. By default this cookie is only visible to the subdomain that sent it, but you can easily change this behavior by setting domain explicitly in web.config file.
Yes Orchard does uses Forms Authentication.
You can find the code for it in (Solution Control of Visual Studio)
Orchard.Framework => Security => Providers => FormsAuthenticationService
You can find how orchard does at the above mentioned path in the void methods of SignIn and SignOut
Related
In our web application's UI, we load a video in an iframe. The video is on office 365/SharePoint server.
If the user is not logged into the organization's portal managed by Azure ADAL, a login screen is loaded in the iframe. If the user is already logged in the video plays normally.
So far fine. But our management do not want the iframe redirected to login page and instead set a cookie on the iframe and load the video.
We said that it is not possible to set a cookie on an iframe and send a request and also we asked how can we get Microsoft cookies into our application? The architect says there is a rest endpoint which will give the details of the cookie. But still we do not have idea how to set it.
Is it really possible to set cookies and send to Microsoft portal to avoid authentication? I believe it is not possible but the architects and management insists we try something.
I would say it's not possible to set a cookie "per frame", but I guess you can login the user ("somehow", see below) and then reload the frame (or check authentication before even trying to load the frame).
Idea to login silently:
Create an account on your SharePoint which is only allowed to watch the selected videos (aka a "Public-User")
Automatically login all not already authenticated users with this account
Maybe with a rest call to the SharePoint server, check whether the user is logged in
If not logged in, maybe in a (hidden) frame send the login data for the Public-User to the SharePoint
All future requests should have the cookie set.
Show them the video
But for the idea to manually set the cookie: Due to security issues, browsers won't let you (= your web application) to read or write cookies for another domain (= the SharePoint server).
Sort of.
We accomplished something like this through the use of a proxy server.
In short, the proxy (hosted in elastic beanstalk) would notice a request coming in, check it's cookies for one that we set to determine the user is logged in, and if it found that cookie on the request it would call some authorization endpoints with it to be able to append a new cookie onto the response (set-cookie header) which we would then use to determine how to proceed. The proxy was written with node.js/express.
As long as you end up having sameSite: 'None' on the cookie options when you are setting the cookie it should work, even though the site hosting the iframe is on another domain.
I'm not sure if this relates into your bigger picture, but maybe gives some inspiration to others with similar issues.
You all know this page.. Is there ANY way to customize this page somehow?
I thought using an iframe and custom the HTML but Google won't let
me embed their websites..
I thought using a Google Site and inserting a login gadget but there
is no login gadget.
What I want is a custom page where my clients can login to their gmail, drive....
What I want it's not impossible, this guys http://www.cloudcodes.com/custom-login-page.html offers you the possibility to custom the login page and even redirect you to another page after you've logged in.
Directly editing the native login page at accounts.google.com is not possible.
However, for Google Apps accounts, you have the option to set up the Single Sign On service, which allows you to authenticate through a third party provider (Or yourself, if you have the ability). What GControl are offering is this service, although they've labeled it misleadingly, to make you believe your actually editing the login page, rather than redirecting your users to a secure login.
They do it very well though, leveraging the Google Apps APIs to allow you to write and setup the service in their own console.
Source: I installed the service and tried their free trial, and they simply used the APIs to enable SSO on my domain.
Edit for clarity: SSO setup is not available for consumer Gmail.com accounts.
anybody know is possible to use Persona for SSO purposes for cross site login which are sub domains of the single domain ? I do no find this useful feature in documentation.
thanks.
If all of the services are within a single domain (e.g. service1.example.com, service2.example.com, etc.), you could set a cookie on the top-level domain directly (example.com) and then all services could use the same session since they would all have access to that session cookie.
So one way to do this would be to redirect users to login.example.com when they click the login button on any of the other sites (service*.example.com). That login service would use Persona to ask the user to login and then it would set a cookie on example.com.
This strategy is of course not specific to Persona, it's a common way to get SSO between internal services within a company for example.
I am trying to analyse the IIS log and would like to look at the broken down by user. I can't do this at the moment because I am using Forms Authentication and IIS is logging everyone as anonymous, which obviously is expected.
Is there a way to configure IIS to retrieve the user details from Forms Authentication?
As you noticed, what you want cannot be achieved as form authentication is designed that way.
In order to do this you'd have to put some sort of identifier in the URL Query String for each page call.
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).