Undertow authentication across multiple pages - security

I would like to make a login page where users provide credentials and then have other pages check if the user is authenticated before serving those internal pages in Undertow.
While the example shows how to authenticate a user (for what will eventually turn into a login page), if the user were to navigate to another page after authenticating, how do I test if that new page request was been made by the authenticated user?
I have referenced http://undertow.io/documentation/core/security.html and https://github.com/undertow-io/undertow/tree/master/examples/src/main/java/io/undertow/examples/security/basic.

This is an ancient question no one answered, but I did manage to learn about Keycloak which is Wildfly (Undertow) + SSO/Secure login.

Related

Security implications of storing user ID in cookie

What are the security implications of storing a user's unique ID in a cookie?
Logging-in is managed separately. The presence or abscense of this cookie is simply used to determine:
Is this a returning user?
If so, who did this user last login as.
These are all merely hints, the user doesn't get any more rights (before login) than a first-time visitor to the site.
Background
My web app front-end is implemented in Angular4 and backend is all APIs and stateless. JWTs obtained from Firebase Authentication are used for authentication. As such, when a user arrives on the home page, I have no way of knowing who the user (potentially) is and whether they are logged-in, till the time the user goes to the PWA (at /app).
When the user goes to the home page of my web app, I want the (stateless) server to be able to redirect them to the PWA if they have logged-in in the recent past (say 2 days). This can be achieved simply by the presence/ absence of a cookie, but I would also like to be able to show them a personalised greeting when /app page loads up.
Very open to suggestions for a better way to achieve this.

Facebook authentication with Express using a custom login page

Currently I am trying to create a login page that would allow a user to authenticate through his facebook account. All the tutorials I found explain how to implement it, but in all implementations their websites take a user to Facebook's login window. I wonder if it is possible to use my own login page to provide a username and password using my own form and then authenticate the user on the server side without any Facebook pages popping up?
Thank you in advance

sharing spring security credentials in multi web module project

There are multiple web modules (wars) in an ear file. Each web-module has it's own spring security configuration.
Lets say, web_module_1.war and web_module_2.war
Now, when user is logged-in to web_module_1.war module and then navigate to url of web_module_2.war. In this case, user is redirected to login page of web_module_2.war even though he is logged in.
How to pass credentials of logged in user to web_module_2.war to avoid login page for logged in user.

ASP.NET Identity 2.0 Users logged out after redirect through Docusign.com

I have a ASP.NET MVC5 web app that uses Identity Framework 2.0 for user administration. On the authenticated side of our app, the users fill out a series of forms, and then are sent through a Docusign in-session powerform. (Docusign Embedded Signing, powerform, url) When the users are finished signing I have set-up callback url's for successful signature and declined to sign events. The successful signature callback is located in the area of my app that requires users to be authenticated, once they get redirected to my site though they are logged out, although they were logged in before they left. I have persistent logins set to true in my login and register action methods, as well as sliding expiration set up on my cookies. Fiddler indicates that when the users are called back from docusign the .AspNet.ApplicationCookie has a different value than before they left.
This only occurs the FIRST time the users are sent to docusign. If a user repeats the process for a second time they are already logged into my site when they get redirected by docusign and the cookie is unaltered.
I'll be closely monitoring this thread, if you have any questions or need clarification or code examples I will gladly provide.
Thank You Wiktor Zychla for pointing out cross-site scripting rules regarding domains and cookies.
The issue was with 30x redirects and set-cookie.
Safari has a bug - documented here
and SO has questions regarding it here
I was having Docusign redirect back into an authenticated area of my site, without the cookies the users were not authenticated therefor they were prompted to login. This did not occur any time there-after because the cookie was already set in place.
My solution was to redirect from external to a public landing page, which then redirected them to the intended authorized page. (since the cookies were set on the public page, they get passed to the authorized page, and the persisted login succeeds)
I also got tripped up with cookies and domains (I was redirecting to www.mysite.com instead of mysite.com)

Gwt + Gae Security: Login page

Google AppEngine's "guestbook" tutorial is very nice and clean.
It's awesome how easy I can authenticate my users via Google Accounts.
Now, imagine if my application was a GWT application.
I can make two pages: Login.jsp and MyApp.jsp then "protect" MyApp.jsp with a simple if / else condition, just like in the guestbook tutorial.
Then my web app will use things like gwt-rpc to ajax-communicate with my services. But...
how can I make this services secure? Do I have to pass them username/password every time and check every time the authentication? Can you tell me more about it?
And what about if I want to use my own Users, instead of Google Accounts? How can I keep my user logged in? By saving the logged user's sessionId inside the User entity for example?
Thx
If the user is logged in using the Users API, all the Javascript RPC calls they make will also carry the authentication cookies required. You can simply check if the user is authenticated using the regular Users API, as you would for an interactive request.

Resources