I think that I have configured web SSO (SPNEGO) on our test 8.5.3 server. I created a test discussion data base and when I access it with a web client my credentials are displayed. But if I acces my Xpage first the #Username function shows Anonymous. If I display the discussion page first then return to my Xpage the #Username gives the correct name.
Any ideas ?
I would check the ACL of the databases and see what anonymous is set to.
I suspect that in the discussion anonymous is set to 'no access' so it triggers the login process via SPNEGO and logs you in with your credentials but the XPage app may have anonymous set as reader so it is just letting you in as anonymous.
When you access the discussion before the xpage app the ltpatoken SSO cookie is being set so when you hit the xpage app it knows your logged in via SSO which is why it is showing the correct credentials in that case.
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.
I have a xpages app. with anonymous access.
For some parts to access I need to login in (I use roles to hide the admin parts of the application)
When I login via a url like http://myapp.com/app.nsf?opendatabase&login I can enter my credentials and I am authenticated to the server and app.
When I navigate to some pages I notice it starts to work with anonymous access again.
So for some reason the server drops the credentials.
Any idea?
Regards,
Peter
Turn off anonymous access for the application that holds the XPages and then turn on the public access setting for those XPages that require anonymous access.
Seems to be a Safari issue.
After cleaning my history and cache it works..
Thanks all for the help.
Regards,
Peter
We have a websphere commerce application running on WAS 7. After enabling global security and application security,on accessing the application url , the browser prompts for login...only after logging in using the server admin credentials,the request is served..is this the expected behaviour of enabling security??
Yes, this is expected behavior. After enabling global and application security, access to application is enforced, if it has security configured in deployment descriptor.
Regarding admin credentials - you are probably using default file registry, with single admin user. You can change who is authorized to access application in the application details page, clicking Map user for security roles. You can specify users, groups, or special subjects like all authenticated and everyone- which would allow to access your app without login, if you really want that.
Has anybody had any success creating an XPage application that includes SSO so that the user logs into notes client and is able to open an XPage application (Database) which uses the Social Enabler to integrate Connections data into the XPage? The key to my projects success is to not need to prompt the user for their username and password (The user has just logged into notes!).
I have seen #nheidloff blog about SSO using the LTPA token between an xpage and connections, however I need this to work within the notes client. If anybody has any success in creating this, can you share any tips please.
I have blogged about a technique...
http://lotusnotus.com/lotusnotus_en.nsf/dx/authenticating-notes-users-for-web-apps-automatically....htm
To sum up, we need a LtpaToken for web-based authentication. We have ability to create an LtpaToken inside Notes client using a Java method of the session object. So my solution has two parts.
A java agent that produces a valid LtpaToken for the authenticated user on the client side. We are calling this java agent from any Lotusscript routine.
The second part is a redirection web page on any database that can be accessed anonymously. This might be a Lotusscript agent, servlet or XAgent. It will get LTPAToken and a target URL from a GET request, add the LTPAToken into cookies and redirect the user back to the target URL.
In Lotus Notes client, any Lotusscript action might call the Java agent, acquire a valid LTPAToken and launch a constructed URL which points to the redirection web page with necessary parameters.
There is a couple of bugs I have detected on Domino Web server. For details of the technique and workarounds about these bugs, you might refer to my blog entry.
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).