For a status application we are using ejabberd xmpp server.
At some times, a status must be set from a web server for a user.
It may be that the user doesn't have an active xmpp session.
I tried with https://docs.ejabberd.im/developer/ejabberd-api/admin-api/#set-presence, but this only works for an active session and valid resource.
How can we "override" the presence of a specified user?
It may be that the user doesn't have an active xmpp session.
When a XMPP client logins to an XMPP account and sets a resource, sends a presence with a status, then a XMPP session is established.
If an account doesn't have an active xmpp session, then there isn't any status to be set, no resource, and no presence to update, right?
Related
While testing the backchannel logout of our OIDC client implementation, I noticed the following behavior in Keycloak when multiple sessions exist.
Preconditions:
Log in the user in the same client using, e.g., two browsers. You will see two sessions for the registered OIDC client in Keycloak
On the user’s sessions tab, click on “Logout all sessions”.
This results in one single backchannel request being performed, where of course I can identify the user through SID (ID of one of the two open sessions) or SUB (internal ID of the keycloak user).
Now you can imagine that the client itself may have internal session information (session cookie, other pieces of information of the client) that you’d like to invalidate/terminate as a result of the backchannel request
However, it is impossible for the client to identify which of the sessions to actively terminate, as seemingly only one of the active sessions in Keycloak will be submitted as a backchannel logout request.
How can I identify as a client which sessions to terminate? Is this a bug in keycloak? (I would have expected one request per session to get both SID logout requests in the client), or some other means of transporting the intent to the client of logging out all sessions of the subject.
Below is my understanding about Kerberos delegation :
1] Unrestricted delegation (W2000): Windows 2000 allows a authorized user to forward a TGT: he asks for a forwardable TGT (Authentication Service) and can then ask for a forwarded TGT (Ticket Granting Service). He may just forward this TGT (with the session key) to a service (krb_cred message). The service may then request a ticket service on the user's behalf for any service and may in turn also forward the TGT with the user's session key to any other service [proxiable/proxy tickets are out of scope since it seems not to be used due to the prerequisites it requires],
2] Restricted delegation (since W2003) : A IT admin can configure a service in the AD (SPN) to be authorized to request a ticket service on behalf of a user for a set of services (SPN) : "Allowed-To-Delegate-To" (A2D2) parameter. Moreover, a new extensions (S4U2Proxy) allows a service to request a ticket service on the user's behalf for an other service since it is able to present a valid and forwardable ticket on the behalt of the user for itself (so, it means there is no need anymore to get the TGT from the user and its associated session key). To get a forwardable ticket for itself, the service shall be tagged as "Trusted-To-Authenticate-For-Delegation" (T2A4D),
3] Protocol Transition (S4U2self) (since W2003) : A service may ask the KDC for a ticket service (for itself) on behalf of the user without showing any evidence to the KDC indicating the user has been authenticated by Kerberos. This can be done by enabling the flag "Use any protocol" in the configuration of the SPN in the AD. Then, it could use constrained delegation if the proper flags (T2A4D and A2D2) are set for this service,
4] Constrained delegation cross domains (since W2012) :
¤ Where before it wasn't possible to use delegation cross domains (because not possible to set a SPN out ot the current domain of a SPN), authorization can now be configured on the target service instead of the source service (conceptually, it's more logical).
¤ A specific SID ($$) may be configured on the target service to authorize or not a delegation when the user was not explictely authenticated by the KDC (it means when a service used its protocol transition ability to get a ticket for itself) : in order for this to work, it means (I guess) that the ticket service granted to the source service for the target service contains this information,
What is not clear to me:
1) After reading MS articles, I understand that forwarded TGTs cannot be used to do constrained delegation although there is clearly the "forwarded" flag in the TGT. Indeed, this is quite different compared to a service which uses its own TGT with a ticket service for itself, because with the user's TGT, the service is authenticated as the user which requests a service ticket. Is there any meaning in using the "adress field" of a ticket request, which is intended to contain the iP/DNS address of the requestor (this could be modifiable of course) ? Is there any parameter to refuse a ticket request when a forwarded TGT is used ? Why not use the adress field (client) to check the associated rights ? Is it because it's not reliable (address may be spoofed) or because it's not precise enough to identify a SPN ?
2) Introducing the SID ($$) implies to me that the forwardable service ticket does contain a specific information saying this ticket was obtained through S42Uself extensions or was directly obtained by the user. But I don't know what it is,
3) Forwarded TGTs seem to be "deprecated" if it means delegation cannot be constrained. So, I don't understand why there are one forwardable and one forwarded TGT (so for delegation) when I display my cached tickets using klist (Windows 10 machine in a corporate environment, and this for two different compagnies). Is is a standard and recommended practice or do I miss something ?
Thanks a lot for your feedback !!
Have a great day.
Arachnide.
Is there a way to revoke/invalidate a user's CAS session from a client application without the user visiting the CAS server's logout page?
The situation is that a user could be accessing 1-n services that all authenticate off the CAS server. One of those client services is in charge of user accounts, and sometimes needs to terminate an account. If that user is logged in to 1-n other services, those sessions need to be immediately destroyed. Normally this is accomplished by the user clicking "logout", but if the user isn't present, that's not possible.
I think you have to check regularly if the ticket has expired or not.
Check this subject
CAS and Spring-Security: regularly check if a ticket has expired
I am integrating against a CAS server. User logs into there, gets forwarded to a script which does the CAS validation, gets the User and logs them in. This all works fine.
Part of the spec for the integration is to ensure we ping the CAS server every 60 seconds, to ensure the user does not get logged out at the 'parent' CAS server, as they are still active.
Is there something built into the CAS setup for this purpose? I've been looking through the CAS documentation and the phpCAS client to no avail. There's a renewAuthentication method but it causes the user to have to login again when called. Perhaps this is just a configuraton issue at the server side though?
There is no way for you to ping the CAS server on behalf of the user as your application should not have access to the token identifying the user's session. The default policies automatically extend the user's single sign on session every time the user requests a new service ticket from the CAS server.
However, if you do have the TGT (which you really, really, really should avoid), you can basically request a service ticket for the user, and that would extend the life of the single sign on session (though if you did this, you would not need to do it every 60 seconds, as that's rather extreme).
I'm going to develop site accessible to anonymous and registered users. Planed security schema is similar to let's say YouTube and most of others "web 2.0" sites. Logged user will get access to more functions, more data etc. What is best approach to implement that?
I'm thinking about create simple service returning random session code to client, and adding session object to singleton application object. When user provide credential, I'll change parameter "logged" in his session object. Session token will be passed as one of parameters in every single request, and services will change their behavior if user is registered or not (i.e. there will be returned only "public" data, or restricted content only)
Is it good approach, or should I use something different?
There is nothing inherently different about GWT security, it is the same with JSP,PHP, ASP, ROR, etc..., that is web application security.
There is already a session mechanism on the server side, that generates secure random session cookies, use it. As a bonus, it handles session expiration and other things you would have to handle if you rolled your own.
You cannot trust ANYTHING the client sends you, so if you send the username or some kind of token from the client to the server (other than the user logging in), you are doing it wrong.
If your information has any value, force SSL on all connections.
Your implementation of the server calls should check the server session for the current user info, and determine if the user is authorized to perform the action. Again, your RPC information should not include any information about the user making the call, other than the session cookie that is sent automatically with the request headers. Anything you store, such as whether the user is logged in, should be in the server side session.
Of course, you need to do something on the client to present logged in and anonymous users with the proper user interface. But that is not security, only work to present a consistent interface. All the security is on the server side.