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.
Related
We are implementing the integration of our existing web resource with Rocket.Chat. We are using the community version of Rocket.Chat. For this, user authorization via OAuth2 has already been done.
Now I am faced with the problem of proactively creating a user (when applying for a job, for example) without the participation of the user himself. Rocket.Chat API allows you to create a user, but it is a normal user (when creating, you cannot specify that this account will be authorized via OAuth and, accordingly, associate it with the account of the web resource).
Another option: on the side of the web resource, simulate a request for obtaining an Authorization Code via the OAuth protocol and send a correct response to this request to the Rocket.Chat server. Thus, the Rocket.Chat server would then receive the user's token and data and automatically create his account. But this is impossible, because according to the protocol specification, when requesting an Authorization Code, the client pass a randomly generated string ("state" field), which is returned unchanged when answering this request, and the server, checking the equivalence of this value, protects itself from such manipulations.
I am also trying to work with the Rocket.Chat Apps-Engine framework, but I still can't figure out how to create such accounts through it.
I would be grateful for any experience or ideas on how to solve this problem!
I am exploring keycloak for my project SSO solution, and I am trying the open-connect on this blog https://developers.redhat.com/blog/2017/05/25/easily-secure-your-spring-boot-applications-with-keycloak/
And I would like to as one question about Single Sign Out, I would like to know what’s the principle behind. Tried to search online document but I didn’t find any clue .For a while, I was thinking there is no elegant solution for Single Sign Out in oauth2 world.
This is the way Keycloak implements it (yes, this is not part of OAuth):
when you use Keycloak to create a server side session in your application using the Java Client, Keycloak will trigger a logout of the session once the logout at Keycloak is triggered. You'll need to set up an Admin URL for your application in Keycloak. This is called "backchannel logout" in the documentation.
When you use Keycloak in a HTML5 client, Keycloak will create a hidden IFRAME that will check that the Keycloak-Cookie is still present. If it is not, the HTML5 application knows that you have been logged out.
OpenID Connect Back-Channel Logout seems to be the way to go nowadays. It works by exposing a special end-point in your application (backchannel_logout_uri), which will be invoked by the OpenID Provider when the user logs out from SSO. Through this endpoint, the Provider gives you a signed Logout Token, to notify your application that the user's session should be terminated.
Because a user may be logged in from multiple devices, browsers, etc., the OpenID Provider can also include a Session ID (sid claim) as part of the Logout token. You can compare it with the sid that you would have received in the ID Token during login, to decide which session to terminate.
The standard back-channel logout was implemented in Keycloak 12.0, which shipped in December 2020. Earlier versions only implemented an alternative, proprietary mechanism.
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).
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.
I'm trying to build the foundation for my iPhone app and server. I have users who will sign up and sign in from the iPhone app. In a normal website login, the http server will provide cookies to allow the user's subsequent requests to remain authenticated. How should I handle this on the iPhone? Should I just send the user/password every single time I have a NSURLConnection GET or POST? That seems excessive. Or do I use the ASIHTTPRequest framework to use cookies. Can anyone point me in the right direction for a proper implementation?
Thanks!
Sending username and password in every request is not great.
You can use anything you want to send cookies. It's just another HTTP header. But that begs the question of what is in the cookie. It depends on what your client/server architecture is. Web apps use session keys because traditionally web clients haven't held any state so the app server had to. Native clients can have all sorts of state and so generally don't need the server to provide that.
But you need authentication. That's what things like OAuth and OAuth 2 are for. They allow you to authenticate once and then use tokens that can be invalidated server-side. Kind of like very long lived sessions without data.
They are a bit complicated but there are open source libraries for both the server and client pieces or you can roll your own. Most of the complication is on getting the original token which you can short-circuit if you own the client and server. OAuth can get pretty complicated because all requests are signed with a secret token. OAuth 2 can be as simple as a shared secret (thus requiring SSL) in a cookie.