I am running a Lab environment with Windows Server 2008 R2 and ADFS 2.0. I am also running Cisco Unified Communications Manager 10.5.1 (CUCM) and Jabber for Windows 10.5.2 which work with SAML 2.0.
When I go to the CUCM web page, I get redirected to the ADFS Forms Based Authentication page where I can authenticate with my AD credentials. I can then login to the web page fine. When I close the web page and re-open it, I am re-directed to the ADFS FBA page once more.
From my understanding, there are two types of cookies in SAML; Session and Persistent. I am also of the understanding that Session cookies are limited to a single browser instance and do not survive exiting the browser while Persistent cookies are available to all browser instances and expire after a set time.
My questions are:
Is my above understanding correct WRT Session v. Persistent cookies?
Are Persistent cookies enabled by default in ADFS 2.0 or do they have to be enabled?
If already enabled, why does the above scenario happen? (looks like to me that only Session cookies are being used)
Thanks,
Daniel
Related
I'm having an issue where my website is not redirecting to Okta when a client is browsing. same code hosted on my dev machine works properly. Okta applications are properly configured (Okta production and OktaPreview for testing). The only difference is that the server VM is not allowed to browse internet. We cannot use search engine or download anything ON the server. Is it possible that this lack of local internet on the IIS server is playing a role in the Blazor Server-Side app not doing anything when user clicks "Login"? The user sees a spinning wheel and the template is shown instead of any error.
As it turns out, even the user's click on a button is execute at server side. So, internet access had to be enabled for all Okta domain on server side and the client is now properly redirected to Okta for SSO.
I was wondering that session management in cloud environments are available in many options for Microsoft azure/ Amazon Web Services / any private cloud. What I was looking that which is the best session management technique which will fit in all the cloud environments.
I have gone through many site but could not decide which is the most suitable in all cases. I read somewhere that Sticky sessions are also one of the option for session management. So looking for an answer which states that is Sticky sessions are different from cookie based session management?
If yes then how to use it?
Thanks
Ravi
Sticky session are likely to stay on same server when the first request comes and provided from same server for each request. Where as cookie based session are nothing but keeping the data on client machine in browser. can be served from any server which is available.
Yes Sticky Sessions are different than cookie based sessions.
As sticky sessions are nothing but handled by load balancers which handles to get sessions in request from client and passes it to the same server where the first request came to that server. E.g. While loading an website request goes to server A, then sessions get stored on server A, while next request comes from user the request sent to the same server i.e. Server A, irrespective of how many servers present in the farm.
Whereas cookie based sessions are stored on client machine, and it gets added with each new request. So it can be read and supported on any server in farm irrespective which server generated and stored session while first login.
I am using a jQuery plug-in to create a cookie (https://github.com/carhartl/jquery-cookie) and have been allowing the cookie to default to a "session cookie". Which is exactly the behavior I would like to have. My concern is that when I deploy my web site to Production, that it will be in a web farm on that environment. Can anyone help me understand what kind of issues, if any, that I will run into with session cookies on a web farm? The version of IIS on the web farm is IIS 7.5.
No issues at all. Cookies are stored on the client. They don't know or care about your server side infrastructure and how many nodes you have.
There are 2 types of cookies:
Session cookies - live only in the memory of the webbrowser and do not survive browser restart.
Persistent cookies - stored as files on the file system for a specified duration and survive browser restarts.
From the perspective of the server it makes strictly no difference. The cookie will be sent by the client on each request and the node that is serving the request will receive this cookie.
If on the other hand you are storing some information in the memory of the web server, such as for example using ASP.NET Session with the default InProc state then you will have problems. But this has nothing to do with client side cookies.
I'm in the process of rearranging our web-based systems, so that users will be able to log on to our systems through a Sharepoint front-end. Our single sign-on server is an Oracle SSO server that authenticates against the same domain as the sharepoint server does, but these two are currently 2 separate logins.
What I'm looking for is to configure this scenario:
A user logs in to the Sharepoint site, authenticating agains Active Directory through the TMG. This gives the user access to the sharepoint site, and this is all standard OOTB functionality. Then the user should be able to navigate into our other systems without a re-login (because the SSO configured for external authentication with the same AD, and therefore uses the same userbase).
So basically the users currently have to login twice with the same domain\user + password. I would like the SSO server to be able to read the cookie that was established in the first login, and use that instead of presenting the SSO login screen all over again.
Is it possible to share such a cookie between 2 different platforms on the same domain?
I have implemented a kerberos "Zero-sign-on" approach for the Oracle SSO server, but this only works as long as the user comes from a computer inside our domain. When the user logs on from the outside world (www) he will be prompted to login to sharepoint first, and then to the Oracle SSO.
I basically need the Oracle SSO Cookie to somehow read the Sharepoint Cookie that was established. Does this make sense?
I have a REST web service running on a Windows 2003 Server. I want to prompt my users from a mobile app to enter their Windows domain credentials. I want to send those credentials to the web service, and cache them for a few days. It appears I can cache the credentials using the low-level Credentials Management functions but everything I've seen so far implies they're made to be called from an interactive session. What's the best way to cache these credentials in a web service?
MORE INFO: The reason why I need to cache the credentials in the Web Service is because I need them to access some back-end resources (i.e. SQL Server, etc.)
You don't typically cache things in a web service.
How are you prompting them to enter their credentials to begin with? That app / piece should cache the information.
It appears that Windows Identity Foundation provides a better mechanism to accomplish what I want. I'll be looking into that.