We have a JBoss EAP 6.3 cluster with 2 nodes. We also enabled SSO.
The thing is, we got a web application that has the login form, so when the session timeout configured in web.xml expires, it redirects the user to that form. The other web applications deployed, on session timeout are redirecting to that form too.
On one hand we got the session-timeout property in web.xml for every web application, and on the other hand we got the SSO enabled in JBoss.
Is the same session timeout value on all web applications correct ? Should we ignore that value and focus on some SSO global session timeout value? Whats the best practice for configuring the session timeout of every web application in this scenario ?
Thanks guys,
Regards.
The Web session and SSO session are differents things, session is create when you access a web application and this can live without autentication. SSO allows authentication to one resource to implicitly authorize access to other resources.
Then according documentation:
How SSO Works
If a resource is unprotected, a user is not challenged
to authenticate at all. If a user accesses a protected resource, the
user is required to authenticate.
Upon successful authentication, the
roles associated with the user are stored and used for authorization
of all other associated resources.
If the user logs out of an
application, or an application invalidates the session
programmatically, all persisted authorization data is removed, and the
process starts over.
A session timeout does not invalidate the SSO session if other sessions are still valid.
So if you want invalidate sso authtentication across cluster, you may call the method Request.logout(), for example.
SSO Configuration Options:
maxEmptyLife:
Clustered SSO only. The maximum number of seconds an SSO
valve with no active sessions will be usable by a request, before
expiring. A positive value allows proper handling of shutdown of a
node if it is the only one with active sessions attached to the valve.
If maxEmptyLife is set to 0, the valve terminates at the same time as
the local session copies, but backup copies of the sessions, from
clustered applications, are available to other cluster nodes. Allowing
the valve to live beyond the life of its managed sessions gives the
user time to make another request which can then fail over to a
different node, where it activates the backup copy of the session.
Defaults to 1800 seconds (30 minutes).
Se also: Use Single Sign On (SSO) In A Web Application
Another thing is not possible configure a default session-timout value in JBoss 7 (Like jboss 4, 5 and 6) so you'll have to configure this value in each application.
Eg. add in your web.xml:
<session-config>
<session-timeout>20</session-timeout>
</session-config>
I hope this help.
Related
We have 3 applications: admin site running IdentityServer, SPA, webapi with rest services.
On the first one (with IdentityServer) we have some aditional admin ui. A requirement exists that the connected user can seamlessly go from our SPA application to this admin ui without authentication. So, from one web application to the other by redirection.
The question is how to keep both 'sessions' in sync so none expires while at least one is in use?
Example of the problem:
Settings of the apps:
spa_web.com - our spa application -> gets the access token valid for 1 hour and a refresh token.
authorityWithIdServer.com - our id provider site -> has a cookie mantaining session set to 1 hour expiry.
Steps:
1. First we go to spaWeb.com.
2. User needs to be authenticated, so is redirected to authorityWithIdServer.com where he fills out the login form.
3. Using authorization code flow, we are redirected back to spaWeb.com and finnaly get the access token and refresh token which are locally stored.
4. We are using only the spa application for a few hours. Our access token is periodically renewed with the refresh token.
5. Now we decide to go to the admin ui present on the authorityWithIdServer.com.
6. We get the login form again to sign in to that application.
Is it anyhow possible to slide the cookie of authorityWithIdServer.com while we are using spaWeb.com in order not to be forced to login again.
You should not be using refresh tokens in client side apps. Change to authorization code and use the silent (prompt=none in an iframe) way of renewing the token. oidc-client-js implements this out of the box along with session monitoring.
If you do the above then since the renewal request happens in the context of the browser via the authorize endpoint and thus authentication with the IDP is done via cookie then any sliding logic will kick in automatically.
Also note that identityserver4 lets you control how frequently a client must interactively authenticate via the authorize endpoint max_age parameter and the UserSsoLifetime client setting.
Our company's application will have centralized authentication. No authentication or user accounts maintained in either App 1 or App 2, all are handled in Identity Server. You need company's account to have app 1 or app 2.
I think id_token is more than enough as session ID but from my understanding, it is preferable not to expose id_token outside the server if possible for tighter security. How should I issue the session_id, what's the ideal way of session management for this case? I am using WSO2 Identity Server
Session management, this is a trait most commonly associated with web applications so I'll assume that's what App 1 and 2 are. You may find this article (Single Sign-On for Regular Web Apps an interesting read, in particular the section on session management.
When talking about managing sessions, there are typically three layers of sessions we need to consider:
Application Session
Auth0 (Federation Provider)1 session
Identity Provider session
1 This would be applicable to you if you planned on having your authentication server further delegate the authentication to additional identity provider like Google or Facebook.
Personally, I would not use the ID token as the session identifier and instead use a shorter ID and keep the session state server-side.
However, the ID token is meant to be provided to a client applications as a way to supply them with information about an authentication operation. Here, client application refers to the role of the application and not its deployment characteristics so you can have client applications that live only on the server world or outside of it in end-user devices/computers.
The previous implies that having ID tokens cross the server-side boundary is completely okay and that your intentions of using it as the session cookie value is fine.
Do have in mind that both cookies and ID tokens have the notion of expiration so having the token inside a cookie may be kind of confusing. You either need to keep expiration in sync (duplication) or ignore one and make sure that everyone knows which one is being ignored (everyone might even mean you three months from now).
These questions are asked based on the spring-security enabled client in mind.
How does CAS SLO work internally especially in invalidating the sessions of the registered services?
For CAS to understand the list of registered service, do we need to have the cas service management webapp in place?
To implement CAS SLO, is it mandatory to implement Ehcache registry or can it be done without that?
How the backend channel logout for invalidating session work?
When the global session in CAS is invalidated, I assume that the tickets related to it in CAS server are removed or deleted. How does the communication happen back to the registered services? What is the best way to debug this if the single logout is not working on the service side?
Wherever applicable, an example or sample for explanation is much appreciated.
How does CAS SLO work internally especially in invalidating the sessions of the registered services?
A callback notification is sent to all CAS-protected applications that have established a record with CAS. The application should capture that notification and destroy its session.
For CAS to understand the list of registered service, do we need to have the cas service management webapp in place?
No, that's just a UI.
To implement CAS SLO, is it mandatory to implement Ehcache registry or can it be done without that?
Can be done without it. The two have nothing to do with each other.
How the backend channel logout for invalidating session work?
See above.
When the global session in CAS is invalidated, I assume that the tickets related to it in CAS server are removed or deleted. How does the communication happen back to the registered services? What is the best way to debug this if the single logout is not working on the service side?
You want to turn on log levels to DEBUG and watch the interaction. If the application is configured in CAS for back-channel logouts, that notification is sent directly from the server. If it's front-channel, the notification is submitted from the client browser.
I have an ASP.NET MVC5-application, using Azure AD to let Office365 users from different organizations authenticate.
However, if the web application is idle for about 20 minutes, the user is redirected to the login page at the next click/reload. Problem is that the user won't notice this right away, because they are not redirected due to updates on the page are async JS-based...which is then not saved to the database. But when the page is refreshed, they are then redirected to the login.
How do I avoid that login timeout after idle for 20 minutes? I don't really want them to be logged out at all.
Thanks!
It's because the encryption/decryption key for the authentication cookie is being generated on application startup. When the application gets shut down from being idle, the next startup the application can't decrypt previously issued authentication cookies essentially logging everyone out.
You'll need to set the <machineKey /> element in the web.config of your application. You can use a service online to generate it or IIS has a built in machine key generator if you don't trust the online services.
From the Valance documentation it looks like the user is always required to enter credentials at the D2L site. Is there a way for Valence to be used, without the user re-entering credentials, when a user is already authenticated by the originating webapplication? Is some type of SSO available?
Yes, In the typical configuration for SSO between a web app and the Learning Suite the same authentication service is used (either the Learning Suite itself, or a separate authentication service , or possibly the webapp that is calling in is also acting as an authenticator in the case of a portal). If any of these scenarios apply, SSO will work as follows:
Authentication is done within the browser so if the user is authenticated already and goes to the authentication service it will already have the session cookies associated with the authentications service. Therefore when the auth step is triggered it will be pass through -- meaning the user is not prompted for credentials (on the first use the user will be prompted to allow access to this app).
Additionally note that Valence APIs do not use session tokens that are subject to hijacking and instead uses ids and keys (http://docs.valence.desire2learn.com/basic/auth.html) that are used to perform signatures. As a result those keys are long lived. Apps do not need to reauthenticate the user to the LMS if they still have keys from a previous execution of the app (these keys will be reset in certain circumstances so callers must be prepared to respond to a reset key). As a result you would not typically reauthenticate a user to the Learning Suite every time the user has a session.
(if the above does not apply other SSO scenarios may possible)