I have an Authentication microservice in Pivotal cloud foundry which is built on Spring SAML2. It is integrated with PingFederate IDP. Whenever this service is invoked from a web application, a JSESSIONID is created. In order for this service to work properly, sticky session needs to be enabled. The http request for auth and the response has to be handled by the same service instance in PCF. However, it is not happening. Request is going out from one instance and response coming back to another instance. Since the response doesn't find the SAML message in current session, the authentication fails. Below is the flow -
Browser-->GoRouter for UI-->Angular UI Service and Nginx Reverse proxy-->GoRouter for API-->Auth Service-->PingFed
PCF allows to have sticky sessions based on JSESSIONID. However, when the web app tries to access Auth service through Nginx reverse proxy, there are 2 VCAP_ID's created for a single JSESSIONID. Due to this, the response from PingFed is not able to reach the same auth service instance from the request went out. So, i would like to know why PCF is creating 2 __VCAP_ID's for a JSESSIONID, when the request comes through reverse proxy?
I tried different storage like redis. But, since the Spring sAML2 works on httpstorage, i was not successful. It will be like hacking the Spring Saml2 which i don't want to do.
I tried to check which app the VCAP_ID's belong to by restage the applications. I got to know that one VCAP_ID was for reverse proxy instance and the other one was for the auth service. So, the VCAP_ID for the reverse proxy is causing the issue and am not sure how to eliminate that.
Expected: PCF should create ONE VCAP_ID for a JSESSIONID per instance.
Actual: PCF creating TWO VCAP_ID's for a JSESSIONID per instance
Related
Right now, I have deployment that is supposed to call web service externally on localhost:7001. I know in my body I will add the xml containing the service I need along with username/password for credentials. But actually calling my web app, I'm not sure how to get the endpoint URL.
You can check endpoint in Weblogic Admin Console
I used "https://localhost:9443/t/carbon.super/api/users/v1/me/sessions" to kill all the sessions.
Service running without a issue. But sessions are still active. What is wrong with me here. I attached images here my response from c# code and response from postman.
There is any webservice providing by WSO2 Identity server, to remove a session for specific user to specific ServiceProvider?
I am using SAMLSSO for many web application and they all are integrating with WSO2 server.
Now let's say scenario is,User is login with 2 application at the same time. I want to logout it from one application.
There is one service provided by logout and it's providing single logout and session will be remove for all application. There is webservice provided by IS or way to achieve logout for one specific application ?
What you are asking is to have the capability of removing a specific participant from the session created in the Identity Server side. I don't see a straight forward way (OOTB) of achieving this.
Closest you can achieve is as below.
Make your application perform a forceAuth. ForceAuth will request for user credentials despite having the cookies in the browser. (This will prevent the user from experiencing the SSO comfort. Still you can authenticate against the IS)
Prevent the application from sending an SLO request to WSO2. Rather, terminate the self(application) session upon logout.
When your application really wants to perform an SLO (logout all the applications, not just yours), your application can send an SLO request to the Identity Server.
Performing a force authentication :
SAML - Send forceAuth=true as a query paramter in your login request. Or else change the SAML AuthenricationRequest payload body to indicate a force authentication as in the spec(Line 2042).
OIDC - Send prompt=login as an additional query parameter in the /authorization request.
You can do this by calling the REST API and SOAP API provided by WSO2 IS. This will remove the session at WSO2 IS but I'm not sure if it will also trigger the SLO to other service providers or not.
Reference:
https://is.docs.wso2.com/en/latest/develop/calling-admin-services/
https://is.docs.wso2.com/en/latest/develop/session-mgt-rest-api/
Trigger a SOAP request getUserProfile from the UserProfileMgtService.wsdl. The default user profile will be 'default' or you can put the customized profile name you used. This will return the details. Grab the user id from this.
Trigger a GET to the API: /{user-id}/sessions with the user-id from step 1 to get the list of all active sessions this user currently have. Go through the list of sessions and find the session ID of the Service Provider you need to clear.
Trigger a DELETE request to API: /{user-id}/sessions/{session-id} with the user id from step 1 & session id from step 2
If users authenticate with Auth0, get a token, and then send that token on every request, what would be the point of ELB sticky sessions? I'm assuming sticky sessions are not necessary with token-based authentication and that the same user could safely hit difference EC2 instances on each request without any strange behavior. Is that correct?
Generally speaking, yes. If you aren't saving session state on the application server itself then you can safely hit different servers for each request and not miss a beat.
However, one thing to consider is what happens during application updates?
Let's say you have a website. Then you update that website with a new menu button which directs users to a new page. If you aren't using blue/green deployments, then at some point in the update process you will have two versions of your app running. So imagine the user goes to your website home page which gets directed to version 2.0. The user clicks the newly added button. This request is fielded by a version 1.0 server and now you've got a 404 error because it has no idea about the new page.
You can use sticky sessions not strictly for session state, but for application version consistency during updates.
Found an issue Forms authentication Cookie not sharing between the requests to service.
Cookie '.ASPXAUTH'generated and sent to Browser from the Login service successfully, but not sending the Cookie to consequent requests for the same service.
Found When Calling service from Cloud app the request using HTTP 1.1 and for Response it is HTTP 1.0
More observations with the user of Fiddler and other tools:
Working fine for the following circumstances:
Running Service and Client website from local development system
Hosting Service and Client on same IIS (local and remote)
Accessing based on URLs, cookies transmitted properly
Not working for the following circumstances:
Hosting service and Client in different IIS servers.
Hosting Service in IIS (or Azure) and Client from local development system
Some more details:
Both requests made for the same service i.e. same domain, same protocal, same port nr, etc.
Updates at 20-12-2012 15:14:
As I said earlier Login functionality working on Ajax call without fail, Fiddler shows the Set-Cookie on Response, but Browser not reading the Cookie.
Tried to read document.cookies on "complete:" event of $.Ajax(), where I unable to read the cookie. means browser not getting or holding the cookie (where Fiddler shows on the Response of the same)
Regards,
Ramakrishna
Using the Forms Auth, have you performed some actions to take the ASP.NET Session out of process and out of server?
You cannot share the session between servers, so you have to either use SQL Session State provider and put session into SQL Azure, or use the Windows Azure Cache and provided Session State Provider to storage the session into a cache.
I'm sure you are good in using internet search engines, but here is a list of good articles to start with (taking the session out of process):
http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_buildingappswithcacheservice_topic3.aspx
http://msdn.microsoft.com/en-us/library/windowsazure/gg185668.aspx
http://msdn.microsoft.com/en-us/library/windowsazure/gg278339.aspx