In my scenario I have logged into an application and am calling a c# function to create a session in my Identity application. Then I am accessing an service provider application which will redirect to identity application. but here the session I have created is not been recognized and Identity asks Login.
Is my logic correct. or need any remedy?
thanks,
Anish.
It should work but there are a few reasons why your session might be lost:
The session cookie is expiring - how long before user is redirected back? Check your session timeout
You are using cookieless sessions - the session identifier in the URL is lost after redirect
You are using the default in-memory session provider and you have more than one webserver - you are redirected to a different host that doesn't recognize your session
If it is none of these, use browser developer tools to check the session cookie and see why it isn't being sent.
Related
I have a rails application and I am using devise for authentication.
When I get logged in successfully on URL http://localhost:5000/,
I try to access http://127.0.0.1:5000/ in the same browser.
I expect to be logged in as soon as I access it on http://127.0.0.1:5000/ but application remains logged out. Whats going on I really cannot understand as I am trying to access both URLs in the same browser?
UPDATE:
my config/initializers/session_store.rb
Rails.application.config.session_store :cache_store, key: '_app'
The fact that you are logged in is store in the session which is stored in a cookie. For security reasons, the browser sends cookies only to the URLs from which the cookie was set.
From the browser's point of view, localhost and 127.0.0.1 are totally different URLs. Therefore the login information stored in the cookie on localhost is not sent to the server running at 127.0.0.1 and therefore the server running at 127.0.0.1 has no information about an existing session on localhost.
UPDATE:
Using the cache_store to store the session doesn't change anything because the information what session in the cache store belongs to the user is still stored in the cookie.
Imaging that your server needs to store all generated sessions somewhere. And if a user comes backs the server needs to know which session belongs to the user. A simplified solution to this problem might be to assign a random number to each session and give the user this number (stored in the cookie). When the user returns the cookie is returned too and that allows the server to load the session by that number.
And a cookie is bound to a domain. This is a security feature of the browser. If it didn't work that way all sessions would be sent to all domains: Google would know if you were logged in to Facebook, every website would know that you have a cookie from your bank...
I have a working site aaa.com with custom membership provider
connected as http module.
I need a create OAuth 2.0 Authorization
Server + Resource Server
Main scenario of using is Authorization
Code Grant.
Here is a good example of creating what I need http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server (see source code of example)
What is my problem:
I want to bind Authorization Server to subdomain of main site -
oauth.aaa.com and when user came from external site to my
Authorization Server, this server check if user is already
authenticated on main site(aaa.com) and if yes - he must just press
Grant button and allow external site access, if no - he must enter user name and password and after this he must automatically be log in
to main site and Authorization Server must be authenticated too.
I've already connected my custom membership provider as http
module(another variant of using not impossible now) to Authorization
Server and Authorize action of this server is already authenticated
when user already logged in to main site.
I don't understand how I must configure Authorization Server(or create some customizations) that it can accept a cookie from main
site(or automatically synchronize and create a new cookie for
Authorization Server using info from already authenticated request).
I was try to configure CookieAuthenticationOptions with same cookie name as cookie name of main site and check that in cookie of main site domain is .aaa.com ...but nothing happend and variable ticket in code = null
var authentication = HttpContext.GetOwinContext().Authentication;
var ticket = authentication.AuthenticateAsync(Auth.AuthenticationType).Result;
Or may be I need another library, not based on OWIN? I saw DotNetOpenAuth library but seems its OAuth client, not server.
I have a CAS-Server and a Client configured via Spring-Security. Single Sign On and Single Logout are working fine so far.
I'm still facing an issue with session timeout. As I understand the ticket expiration policy is not affected by idleness of the secured CAS client side session. So a client must actively revalidate a ticket to see if it has expired and is not being posted the expiration event by the CAS server as it is the case when a single logout is performed.
To force my spring secured client to regularly check for the expiration of the ticket I might set the session timeout to a low value like a minute or so. But that has the drawback of all my session data to be removed. Not very user friendly.
Is there a way to tell spring-security to regularly check if a ticket is still valid without destroying the user session first?
I would be pretty confident on the Javascript solution as it's just a simple check to force local logout. Though, it needs to customize your CAS server, that you cannot do.
You have the solution of having a shorter session on application side to force regular re-authentication, but this means that you will invalidate often your application session and recreate it.
A better solution can be based on the gateway parameter of the CAS protocol : using this parameter will not produce a service ticket if you are not SSO authenticated. So you could have :
an application filter which, every 5 minutes, saves the current url, triggers a CAS round-trip with gateway=true and a specific service : http://myserver/myapp/checkCasSession
a specific url : /checkCasSession : if it receives a service ticket, everything is ok, the CAS session is still valid, it just restores the original url. If there is no service ticket, the local session must end and a local logout is triggered.
I think there is no such way. Spring Security and Spring Security Cas are implemented as a set of Servlet API filters / listeners. So Spring Security Cas works only during some Http request / Session event processing. I do not view any dependency on some scheduling library for spring-security-cas.jar.
It's not an easy problem you can address out of the box with Spring Security. You need to work on both sides : client and server. I would :
create a controller on CAS server side which returns a JSON indicating if the CASTGC has expired or not
every 5 minutes (for example) and each time an application page is displayed, add some javascript to call this specific CAS controller and if the CAS session has ended, ends also the application session.
You need to call the CAS server from front channel as the CAS session is held by the CASTGC cookie.
You have two sessions : the application one with its idle timeout and the CAS one with idle / hard timeouts. After having accessed the application through CAS login, the application session lives on its own and can last more than the CAS session. It's generally not a problem. What use case do you want to handle ?
While using a SSO to integrate between disparate "web applications", the user might switch back and forth between these applications. As the user navigates between these applications, a local session gets created on each of the applications in addition to a session created at the Identity Provider that is used for sso.
So, the issue is when applications have different session timeouts, leading to a broken user experience. Session timeout occurs in one application while the user is working on another application. When navigating back into the application the user had visited previously, an error occurs. This is confusing to the user, since they are not aware that they are working on different applications.
One way to avoid the problem is to have a "global session" object that every application has access to. While the user is accessing any protected resource, the application checks if the global session exists and updates its timestamp before processing the request. The local sessions will never expire (or have a very long timeout). However, when the user logs out, global session object is evicted and the sign out happens on all the applications.
This seems to be a bit heavy handed due to:
Global session object becomes single point of failure
The performance to make a "out of process" check for the global
session object and update the timestamp on access of every
protected request
Any other thoughts on how to make this work?
When navigating back into the application the user had
visited previously, an error occurs.
I don't think that would be an error. The application will redirect the request to SSO provider and as the user is already have a valid SSO session it will be a successful SSO operation and the application can re establish a new/expired session.
I'd appreciate any thoughts/insight any of you might have on this...
I have two domains running the same applications e.g. mysite.com and mysite.org and I have a requirement that when a user logs into mysite.com then he should also be logged into mysite.org. Obviously, I can't set the cookie on another domain but I want to come up with a reasonable, secure solution. I think I have a solution (on paper), but I'd just like some feedback on how to improve & secure it.
My sessions table looks like this currently:
id: auto-incrementing; only used for by ActiveRecord
uuid: Universally Unique Identifier used for session lookup
user_id: the user this session belongs to
user_ip_address: the user's IP address
created_at: self-explanatory
updated_at: self-explanatory
My current logic for authenticating on one domain:
User tries to access mysite.com/some_protected_info; they are no authenticated so they are redirected to the login page (the referral URL is stored in a cookie)
User successfully authenticates on mysite.com; a session is created in the DB; a cookie for the mysite.com is created; user is redirected to the referral URL in the cookie i.e. mysite.com/some_protected_info.
My proposed logic for authenticating on two domains:
User tries to access mysite.com/some_protected_info; they are no authenticated so they are redirected to the login page (the referral URL is stored in a cookie)
User successfully authenticates on mysite.com; a session is created in the DB; a cookie for the mysite.com is created; user is then redirected to a mysite.org e.g. mysite.org/login/special
The login controller's special action looks up the session, sees that it's valid and sets the cookie on the mysite.org and redirects back to another controller action on mysite.com.
Given that the user is authenticated on mysite.com (and presumably mysite.org) the user will be redirected back the referral URL (mysite.com/some_protected_info).
Of note:
- Both sites are using SSL.
- Both sites are using the exact same code (mongrel instances) - the Apache config makes it accessible via different domains i.e. the config.action_controller.session settings on both domains are exactly the same.
Questions:
In (2) should I pass in the UUID via SSL or is that a security concern? Should I generate a new, random, temporary ID to lookup the session?
In (3) should I be passing the referral URL around (mysite.com/some_protected_info) or is it safe just to redirect back to the value of the cookie on mysite.com?
Any gotchas? Special situations that I'm overlooking?
This is not a real answer but if you own the two domains you can set your cookies using cookies cross domain policy:
for example you can create a crossdomain.xml on yourdomain.com:
<?xml version="1.0" ?>
<cross-domain-policy>
<allow-access-from domain="yourdomain.org" />
</cross-domain-policy>
A simple design for a sign-on system that works across domains depends on their being a single point for authentication that other domains can use to verify session information.
Typically the sign-in mechanism is an HTTPS protected page that is capable of verifying credentials and issuing a session ID that can be verified remotely. In practice one domain will forward the visitor to the sign-in page for authentication, then the sign-in process will redirect the visitor back to the original site with some kind of session-ID parameter passed along that can be assigned to a cookie by the original site.
For applications with only moderate security requirements, the session ID value can be encrypted or hashed using a "secret key" known to both the sign-in system and the other domains. This is used to prove that a user's session ID has been issued by the sign-in system and isn't just arbitrary. This is not unlike hashing a password with a salt for verification purposes.
While UUIDs may seem sufficiently unique, the generator may produce predictable numbers, or numbers with insufficient randomness. That is why sending a "signing" value is useful to preclude spoofing.
The idea you have seems fairly solid, but the details matter. It may be worth studying things like OpenID for how they handle session authentication via their protocol.