In my grails application I'm using the spring security core plugin.
Is there any method that returns me a jsessionid for a given user simply by providing username and password
Something like this jsessionid:
def myjsessionid = getJessessionidFromUser("username1", "password1")
I'm not familiar with grails, but Spring Security itself provides Concurrent Session Control that can maintain a SessionRegistry. This registry will contain info about all user sessions that you can query e.g. for getting the sessoin id(s) of a given principal.
Use SessionRegistry.getAllSessions() to obtain a list of SessionInformations related to a given principal/user, and then getSessionId() on those objects.
The concurrency control feature is normally used to limit the number of sessions a user may have, but it can be configured not to enforce such restrictions (just maintain the registry). See more about that in the Session Management chapter.
Related
I have 4 sessions namely Default, Extended, Programming and Supplier session.
The jump to supplier session will happen via extended session. Default -> Extended -> Supplier
But before jumping to Supplier session I need to provide security access.
Once the security access is provided then only the jump should happen to Supplier session.
As per the ISO 14229 - 1 document the security access service is NOT applicable in default session but it is APPLICABLE in Non-Default session. So does it mean security access can be applied between 2 non-default session?
You can configure security level basically for every diagnostic service, even subservice (like for specific DIDs). What I understand you want to do is to require security level for changing into Supplier session, which is definitely possible to configure.
In my opinion, There is no security level required to enter any session.
To perform any action in any session other than default, we need security level.
Example :
1. To execute any service
2. To Read/write a DID
I have two models doing login (Devise) in my Rails app - Admin and User, both currently use the default cookie store for session data.
I want to be able to identify an Admin session in AJAX requests coming in from the admin, for authorization of these API calls. I plan to do this by setting an encrypted cookie upon Admin login. When the AJAX API call comes in, I open the cookie, grab some identification from it and look for a matching existing Admin session in the store.
As I understand it, to do this, I must have session information stored in the back-end, either by DB or memcache stores.
I expect to have millions of sessions of Users and just a few sessions of Admin at any given time. For this reason, I don't want to just move all session information to a DB or memory, since this is a heap of unneeded data to store. I only want to store/look at Admin session data.
A solution will be creating some custom model which enumerates Admin user sessions, and is maintained by the app. This is simple enough but requires for instance, a way to clean up sessions when they die without signing out. Essentially this is an attempt to duplicate Rails's session store mechanism, which comes with all the problems of storing and maintaining sessions. Instinct tells me to avoid this solution. Am I correct to avoid it?
If so, then my question is, is there a way to configure multiple session stores in a Rails app, a different store for every logged in Model? In this case, have Admin sessions stored in memory, and User sessions stored in cookie. If not, I'll greatly appreciate any comments and suggestions.
Thanks!
You may be thinking about it wrong.
Session are a low level mechanism that you build your authentication on top of. Its just a cookie containing an identifier (a random hash) which is linked to a session storage (by default cookies). This is a simple mechanism to add persistence to a stateless protocol.
Confusingly we also use the concept "sessions" when talking about authentication - for example logging a user in is often referred to as "creating a session". This is complete poppycock as we are just storing a claim (often a user id) in the session that was created when the user first visits the application.
If so, then my question is, is there a way to configure multiple
session stores in a Rails app, a different store for every logged in
Model?
No. Thats a chicken-vs-egg conundrum. In order to know which session storage to use you would need to access the session storage to know which session storage to use... you get the picture.
While you could create your own session storage mechanism that works differently does this is most likely a complete waste of time. Premature optimization is the root of all evil.
As I understand it, to do this, I must have session information stored
in the back-end, either by DB or memcache stores.
Not quite true. You can perfectly well build an authentication solution with just the cookie storage. In that case Rails just keeps a record on the server of which session identifiers are valid.
The main reason you would need to store additional session information in the database or memcached is if you need to store more data in the session than the 4093 bytes allowed by a cookie. Cookie storage is after all much faster and does the job fine 99% of the time. YAGNI.
You should also recognize that not everything needs to be saved in the session storage. For example the Devise trackable module saves log in / out timestamps on the user table as part of the process of authenticating a user. This is "session information" yet has nothing to do with session storage.
I want to be able to identify an Admin session in AJAX requests coming
in from the admin, for authorization of these API calls.
There are many ways to use different authentication logic for different parts of the application such as Warden strategies. For an API you may want to consider using stateless (and sessionless) authentication such as JWT.
We are able to save/retrieve data to/from GemFire through Spring Session management.
session.getAttribute(sessionKey) // session is from gemfire.
In GemFire Pulse, we are able to see the session ID by using the query...
select * from /regionName.keySet
How do we see the attributes and values stored against a particular session id?
The short answer is "you can't", at least not using pure GemFire API, which includes gfsh, PULSE and/or direct OQL execution through the QueryService.
You might, however, achieve this use case programmatically using the Spring Repository abstraction; specifically through the FindByIndexNameSessionRepository, already supported by Spring Session for Apache Geode/Pivotal GemFire.
Hope this helps.
Well, this is not entirely true.
It is possible to inspect the Session object, the Session attributes and the Session attribute values (i.e. application domain objects store in the Session) using very carefully crafted OQL query statements, in either Gfsh or Pulse's DataBrowser Tool (extension).
When using Spring Session for Apache Geode/Pivotal GemFire (SSDG), you can use the following OQL queries to inspect the Session (e.g. HttpSession).
You must be mindful, that certain OQL queries, depending on the Serialization format, may cause your application domain objects, or even SSDG's Session objects to get deserialized, in which case, you need to put SSDG, all of SSDG's dependencies (e.g. the core Spring Framework) and your application domain object types (i.e. classes) for the objects stored in the Session on the server(s) classpath.
Also see this related SO question/answer.
Hope this helps!
I'm working on a Grails application and want to integrate with a custom single-sign-on service (not CAS, but similar). I'm struggling to find all the pieces that I need to customize to make this happen. Can someone explain to me a general outline as to what I need to use to accomplish this? I've read the documentation on the plugin, but it assumes I know which beans to override and where to put all the needed files.
I've block-quoted what I think needs to be done based on my research below each point.
Order of Operations
1- The user requests secure content (everything is secure in the application for now)
I believe this setting is in the Config.groovy file:
grails.plugins.springsecurity.rejectIfNoRule = true
grails.plugins.springsecurity.securityConfigType = "InterceptUrlMap"
grails.plugins.springsecurity.interceptUrlMap = [
'/**':['ROLE_ADMIN']
]
2- Spring Security checks to see if the user has a specific value set in a cookie provided by the authentication service
I'm guessing I need to create an authentication filter, but I don't know where to put it or what it should look like.
If they don't, the user is redirected to this custom SSO service, they login, once authenticated, the user is redirected back to my application (with a new cookie set)
3- Spring security checks for the cookie value and validates it against the custom service (via HTTP POST)
From some research, I think that I need to use PreAuthenticatedProcessingFilter, but I haven't been able to find any examples of how to do this.
4- The custom service returns a series of name/value pairs, a user then needs to be created in the local application database (or the timestamp of "lastLoggedIn" is updated if they user's data is already in the database)
I believe this is done in the same PreAuthenticatedProcessingFilter as number 3 or in a GrailsUserDetailsService
5- The user's authentication is cached in the session for a period of time (6-8 hours) so that re-validation against the SSO service doesn't need to occur every time the user requests a new resource.
I'm not sure if this is something that's done inherently or if I need to add code to do this (and also set the session timeout)
We got our own central session management. Generally user can authenticate over it with an username and password, and as a result he gets an session_id. All other operations are done with that session_id. Let's say that the session management is accessed by a XML RPC.
I have two cases to implement:
Central web application made in Spring, which has login form
External web applications also made in Spring, which are relying on
passed session_id only.
Few more notices regarding system:
- session_id is stored in a cookie (after successful login, I have to add cookie to a response)
- every page request has to check session_id validity in session management system
I'm quite new to Spring, so I'm struggling to understand where and how to implement my custom logic.
My questions are:
What parts of a system I have to implement to have my own login
logic (got to have access to a response object too - to set cookie)?
I tryed something with extending UsernamePasswordAuthenticationFilter and implementing my own
AuthenticationManager, but I'm not sure that I'm going the right
way.
Is there point where/how can I implement my "every request session
check" in Spring Security manner?
session_id is stored in a cookie (after successful login, I have to add cookie to a response)
Do this in a AuthenticationSuccessHandler that is configured into your <form-login> element:
<form-login authentication-success-handler-ref="authenticationSuccessHandler"/>
External web applications also made in Spring, which are relying on passed session_id only.
Create a new filter where you check for the session_id cookie. If the cookie is not present or if it is invalid redirect to the central web application for the user to log in. If the cookie is present and valid and the user isn't already authenticated then create a new Authentication and add it to the SecurityContextHolder.
Take a look at RememberMeAuthenticationFilter.doFilter() for an example of what you want to do in your filter.
Add this filter to the filter chain using the <custom-filter> element.