Once I login to my wso2 WASA server. If I am not working frequently inside the
server, next time when I click any service or button it will again show the main login page.
How can I resolve this to keep the server active in the web browser for longer period of
time without re login each time..
Can anyone help in this
You can increase the management console session timeout in AS_HOME/lib/core/WEB-INF/web.xml
<session-config>
<session-timeout>15</session-timeout>
</session-config>
You have to increase the session timeout for your server instance
Related
Is this a right use case for deploying the same in app engine while using memcache service.
An Application that can take request for about 10000/min .
It take the request , check if it is bot then redirect to failureurl
If request is fine then it hit the server to get a charging url and other details from memcache and redirects to a consent page , where we put the charging url on yes button.
When the customer hits on yes button then the person will be chaged and thankyou page will be shown
Judging by what you are mentioning, I would use Kubernetes rather than App Engine for your case, this is due to the "take request for 10000/min" that you mention. App engine cuts the requests that take more than 60 seconds to respond. You can check more about this over at this document: https://cloud.google.com/appengine/docs/standard/python/how-requests-are-handled#specifying_a_request_deadline
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
I'm currently using WSO2 Identity server along with several service providers. I have also configured Single sign on between them.
According to the documentation a system admin can configure a validity in seconds for any SSO sessions under /repository/conf/identity.xml, so that an user can enter their credentials, tick "remember me", and log-in to any service provider while the session is still valid. However, changing this value doesn't seem to have any effect. Users can still log-in to the other service provider even when the SSO Session has supposedly expired.
Searching a bit more threw this JIRA on WSO2 Oxygen Tank, describing exactly the same problem and has a patch that calls setMaxAge on the "Remember me" cookie, but this hasn't fixed the issue.
Furthermore, according to this question sessions in memory must be persisted after 15 minutes, and the persistence doesn't work properly. There are a few patches. Yet still, when I try a value of, say, 30 seconds, I can still log-in on another service provider after the SSO session has supposedly expired, so I don't think it's a persistence issue since the session is still on the cache.
How exactly is the session expired on the identity server? Does it send LogoutRequests to every configured service provider on timeout, or is the expiration only valid for new sessions?
How exactly is the session expired on the identity server?
By default Identity Server 5.0 have session for 15mins and it only can reduce the time using the web.xml (which is at <IS_HOME>/repository/conf/tomcat/carbon/WEB-INF/ folder)
If you installed Service Pack 1 for the Identity Server 5.0, it have the session persistence as well. So using that
Identity Server's session timeout can be increased as mentioned in the docs.
Does it send LogoutRequests to every configured service provider on timeout, or is the expiration only valid for new sessions?
Identity Server session timeout only valid for new sessions, and it does not send any LogoutRequests to service providers to invalidate existing Service Providers' sessions.
I'm new to the SSO world and I've recently installed WSO2 Identity Server 5.0 and done my best to hook in a service provider but I just can't seem to figure out how to make SSO happen.
Here is my current situation and goal:
I have a MojoPortal website where a user can log in. From there, the user can click a link to our FTP site powered by GoAnywhere. We want the user to be logged into the FTP site just by clicking the link instead of having to log in to it as well. The FTP site is SAML2 enabled so I chose the WSO2 ID Server to give SSO capabality between my mojoPortal and goAnywhere sites.
Here is what I think needs to happen - sanity checks welcome:
1. User clicks to access the FTP website and my mojoPortal website needs to create a SAML request and send it to the ID server. I can't seem to get a grip on doing this from an ASP.NET page.
2. ID server gets the request and validates it (you can test the request in the "SAML Request Validator" tool in the WSO2 console, right?)
3. ID server sends a response to the GoAnywhere FTP site which can be simulated with the SAML Response Builder tool in the ID server console.
4. The FTP sites says either OK or NO to access.
5. Not sure what happens next - how does the user get redirected to the FTP site.
So I have big issues: I don't understand the flow in great enough detail and I'm also having difficulties in getting the technologies to work together.
Any comments / help at all are greatly apprciated!
MojoPortal website - is this SAML2 Web Browser based SSO supported? If yes, then the solutions is clear.
You just have to register your 2 sites in WSO2 IS as SPs.
Then what will happen is , once the user log-in to the MojoPortal website, he user will have a live login session, therefore once he clicks on the FTP site, he will be able to access it without having to log-in again.
Hope this clarifies your doubts.
How long can I use a session cookie? I have a client application where I authenticated to a SharePoint site and I am using the cookies for navigating through the subsites. I am saving the cookie and reusing the headers to login to the site at a later point without authenticating again. There is no expiration date set. How long will the cookie last and when should I authenticate back again?
The expiration of session cookies varies from browser to browser. I was unable to find any kind of reference giving the current specifics per browser. It used to be that session cookies would be destroyed when the browser was closed, but some browsers now have settings that, if enabled, will cause session cookies to persist past the browser being closed. For example, Firefox's "When Firefox starts: Show my windows and tabs from last time" will cause this to happen, somewhat surprisingly. The same goes for, "On startup: Continue where I left off" in Chrome.
I don't really care for SharePoint so I haven't used it in a while, but as I recall it uses ASP.Net Forms Authentication, pulling the configuration from the web.config just like any other ASP.Net site. That being said, you're not really concerned with the timeout of your cookie. What you care about is the timeout of your server-side session token - that is to say, how long the data contained in said cookie will be recognized by the server. That is set by the timeout property in the forms tag of the web.config file for an ASP.Net app:
<system.web>
<!-- ... -->
<authentication mode="Forms">
<forms timeout="2880" />
</authentication>
<!-- ... -->
</system.web>
If there's no expire it's going to be around until the browser is killed. Normally in ASP.Net the session cookies are set with a 20 minute timeout. That's usually pretty good. Depending on your app, you may want a javascript timer as well. Otherwise the browser won't understand when it's logged out until a page refresh happens and sensitive data can be exposed. You'll see this implementation on any online banking site.
(Edit to clarify from downvote)
Session cookies do, in fact, stay around until the browser is closed. You can look it up here: http://www.allaboutcookies.org/cookies/cookies-the-same.html
The above answer is also correct in that some newer browsers will recover session cookies after a crash/close.
#Grinn, you do bring up a good point able the Ticket. When using ASP.Net Forms auth, an encrypted Ticket is placed within the session cookie. They cookie can still be in place as far as the browser is concerned, but if the datestamp inside the ticket is expired, it will be considered invalid.
If you're using some semblance of Forms auth with Sharepoint, you should probably just write your own membership provider that can crack the Ticket in the cookie, but disregard if the datestamp is expired. Building Custom Membership Provider