We are currently using WSO2IS 5.3.0 for authentication, and using Pac4J as a session cache in our application. Each API touches the session cache to keep alive the Pac4J session (so it expires after N minutes of inactivity).
Can the WSO2 session cache be touched in the same way? If so, what's the best method to do so (without too much chatter between WSO2 and our application)?
Whenever Pac4J session is expired you have send authentication request to WSO2 Identity server as per the protocol you are using SAML, OAuth2 ...etc. At the time you send authentication request if IDP session already expired you will be redirected to authentication (login page). If IDP session is not expired you will get authenticated assertion without re-authentication. You can refer [1] about how to control IDP session.
[1] https://docs.wso2.com/display/IS570/Configuring+Session+Timeout
Related
I am using wso2 apim 4.0.0. I would like to customize (set 1 minute) session timeout for management consoles(publisher, devportal, admin). The way I am following is the official [documentation] (https://apim.docs.wso2.com/en/4.0.0/install-and-setup/setup/security/securing-api-m-web-portals/#configuring-session-time-out) which states to add following lines to deployment.toml configuration file
[tomcat.management_console]
session_timeout = "30m"
[tomcat.global]
session_timeout = "30m"
I tried to modify those configs to 1m:
[tomcat.management_console]
session_timeout = "1m"
[tomcat.global]
session_timeout = "1m"
After restarting, only carbon seems to be affected from changes given above. It invalidates session automatically after a minute. But session timeout for Publisher, Devportal, Admin portals remain unchanged.
I expected the configuration would work on Publisher, Devportal, Admin as well so they invalidate the session after one minute.
I think this is no longer applicable for the publisher,admin and deportals as APIM use OIDC SSO session management methodology for these portals. Portals use IDP side sessions only and by default, it expires at 15mins[1]. From the APIM UI side, we don't use browser sessions and we only check the access token validity period(default 1 hour), if the token has expired we log the user out and might use the refresh token if persisted and then use that token to get a new access token. During that period if the IDP session has expired only the user is redirected to the login page, otherwise the user login happens and the user is redirected to the portal automatically.
Therefore instead of using the above config, you can
Change the session timeout parameter of the resident keymanager from the management console [1]
Update the access token and refresh token timeouts for the publisher, devportal and admin portal service providers.
[1] - https://is.docs.wso2.com/en/latest/guides/login/session-timeout/
We are using WSO2 Identity Server 5.3.0. I configured trust between WSO2 IDP (symbolic name "IDP1") and the Service provider (symbolic name "SP1"). Then I configured second trust between WSO2 acting as a service provider ("SP2") and federated IDP (symbolic name "IDP2", some public/gov service). SP1 protects some resources, access to them is granted only when users are authenticated to IDP2. Everything is based on SAML protocol.
Login works fine - login requests are redirected from WSO2(=IDP1) to IDP2.
IDP1 initiated logout works fine too.
But IDP2 initiated logout fails with message (in a browser): "Attention: Something went wrong during the authentication process. Please try signing in again." It generates the record to the WSO2 log: "{...DefaultRequestCoordinator} Context does not exist. Probably due to invalidated cache".
During the IDP2 initiated logout correct LogoutRequest is sent to WSO2 (https://amsrv.mydomain.org:9443/commonauth).
Does WSO2 support such scenario (IDP2 initiated logout)?
SLO is working based session ID. You cannot invalidate a session that is not recognized by the IDP.
Your log seens to indicate that the context [pointed by the session id provided in the SLO request] does not exist so cannot be terminated.
Please deactivate Ciphering on the flow, put a Wireshark and look at it. WSO2IS is providing a screen in user dahsboard to see which session are open and with which ids.
I suspect that IdP2 is sending the session ID of the session between Client and IdP2... not the session ID of session between Client and IdP1.
Jeff
We are going to be using WSO2 Identity server to authenticate users into a web portal. The web portal will contain many sso links to other systems. Currently, the only identity protocol we are using is CAS (From Ellucian).
Our issue is when someone logs into our web portal, using CAS from wso2, then that user browses around through the portal for 10+ minutes, then that user clicks a link to a service relying on the wso2 session, that session has timed out, and the user must log into wso2 again.
Is it possible to programatically extend the user's session by sending something from the web portal periodically? Like a URL call saying "Hey, I'm still using the wso2 session, don't end it please!".
Any request that you will make from that browser to WSO2 IS from your application e.g. portlet, servlet, that will access session will automatically extend it.
If you are using the SSO features of IS, it has a default session idle timeout of 15 minutes. You can increase this timeout as described in [1]. As this is a idle timeout any request that access the session in the IS will delay the session expiry time as described in this answer
[1] https://docs.wso2.com/display/IS510/Configuring+Session+Timeout
Environment - WSO2 IS 5.0.0, sample app
I could invalidate sample application session. but I need to destroy user session in IDP along with sample application session.
Is this a out of the box feature in wso2 ?
If not, how can I do it using IS 5.0.0 or is this supported in IS 5.1.0 ?
Please find answers for your questions.As I remember, you have to install service pack2 to send IDP initiated logout request.
WSO2 IS(5.0, 5.1) does not provide this facility as an out of the box with SP initiated sso.
You can use IDP initiated sso.The flow is explaining in the below.
i). you have to send an IDP initiated logout request to identity provider.
Request should be look like this - https://localhost:9443/samlsso?slo=true
ii). when IS receive a logout request, IS send logout request to other service providers those are configured with IS.
iii). Then invalidate other service providers sessions and service provider send a logout response to IDP(IS).
iv). After receive logout response from service providers, IS destroy its user session for particular user and send a logout response to service provider which requested the logout request.
v). service provider invalidate its own session.
Currently we are using wso2 IS 4.1.0 version, entitlements service for policy decisions. As entitlement service is a secured service we authenticate and get the cookie then pass the cookie along with the entitlements service requests. we are using jsessionid cookie and ran into a situation where if the wso2 is goes down we have to restart our app as it has a stale cookie we refresh the cookie on a time interval every 15 min. Is there a way in wso2 is to persist the cookie if it get restarted. we tried commenting the inside wso2is-4.1.0\repository\conf\tomcat\carbon\META-INF.
Can you suggest on how we can configure for persistence of jsessionid cookies in wso2is
Thanks
Kishore
User session (jsessionid) is not persisted in server side. So you can re-authenticated after 15min and get a new jsessionid. (If you received an authenticate failure, you can re authenticated). you need to implement PEP in such way.
If you are using basic authentication to authenticate with entitlement service. You can send both cookie (jsessionid) and basic auth header... if cookie is valid it would be authenticate with cookie, if not use basic auth headers and returns the new cookie to client. you can find some java code for this here.. but this is not for entitlement service but you can use....
[1] https://github.com/soasecurity/soasecurity/blob/master/user-mgt/client/remote-user-400/src/main/java/org/soa/security/sample/user/mgt/SampleUserRoleMgtClient.java