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
Related
I am using Spring Security and I have created a ApplicationListener for HttpSessionDestroyedEvent (for logout and session expiry events). But this listener's onApplicationEvent method is called on login also which looks like a inappropriate behavior. How do I make this working. Below is the code:
public class MySessionDestroyListener implements ApplicationListener<HttpSessionDestroyedEvent> {
#Override
public void onApplicationEvent(HttpSessionDestroyedEvent httpSessionDestroyedEvent) {
httpSessionDestroyedEvent.getSecurityContexts();
// business logic
}
}
You should be prepared to that. The servlet container generally creates a session before the user is connected. When spring-security authenticates the user, it first close that previous session and creates a new one.
That means that an event HttpSessionDestroyedEvent is triggered both on login and logout. You can differentiate those 2 kinks on event by storing for example the user name in session. If it is present, the session was a regular one and it makes sense to call your business logic, if not it was just a technical one and you shoud just ignore it
If your login page uses a HTTP session in a Servlet 3.0 or older container, the Session Fixation Attack Protection will destroy this session and create a new one (migrateSession), see Spring Security Reference:
Session Fixation Attack Protection
Session fixation attacks are a potential risk where it is possible for a malicious attacker to create a session by accessing a site, then persuade another user to log in with the same session (by sending them a link containing the session identifier as a parameter, for example). Spring Security protects against this automatically by creating a new session or otherwise changing the session ID when a user logs in. If you don’t require this protection, or it conflicts with some other requirement, you can control the behavior using the session-fixation-protection attribute on <session-management>, which has four options
none - Don’t do anything. The original session will be retained.
newSession - Create a new "clean" session, without copying the existing session data (Spring Security-related attributes will still be copied).
migrateSession - Create a new session and copy all existing session attributes to the new session. This is the default in Servlet 3.0 or older containers.
changeSessionId - Do not create a new session. Instead, use the session fixation protection provided by the Servlet container (HttpServletRequest#changeSessionId()). This option is only available in Servlet 3.1 (Java EE 7) and newer containers. Specifying it in older containers will result in an exception. This is the default in Servlet 3.1 and newer containers.
When session fixation protection occurs, it results in a SessionFixationProtectionEvent being published in the application context. If you use changeSessionId, this protection will also result in any javax.servlet.http.HttpSessionIdListener s being notified, so use caution if your code listens for both events. See the Session Management chapter for additional information.
There are some solutions for that problem:
don't use session for login page (in most cases not possible)
update to Servlet 3.1 container
change the Session Fixation Attack Protection to none(not recommended)
adopt your business logic
Researching I found how to change the life of a token by using the powershell command
set-ADFSRelyingPartyTrust-TargetName "your app display name Relying party in ADFS trust"-
TokenLifetime "value in minutes"
My problem is that once time passes I need to log out,I do not know if this is possible, thank you for your help.
The token lifetime and your session lifetime are two different things. If you want automatic log out you can do it by configuring the session cookie lifetime at your relying party:
Windows Identity Foundation - relying party session security token lifetime
Good overview here:
ADFS 2.0 time out and relation between Freshness Value,TokenLifetime and WebSSOLifetime parameters.
Essentially, there are two parameters:
WebSSOLifetime:
This is a server wide setting which applies to all the RP’s (Relying Party).
TokenLifetime:
This is a RP level setting which applies to a particular RP. It will not affect other RP’s configured in the ADFS server.
Key point:
In order to prompt a user to re-authenticate, we require WebSSOLifetime to be lower than the TokenLifetime.
This almost sounds like a duplicate of my question
How to set the timeout properly when federating with the ADFS 2.0
What I had to do was to have a local event handler that deletes the cookie but also make sure that ADFS doesn't automatically renew thr session.
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.
I have a cics application and i don't want to develop an login screen, instead i want to restrict the access by fetching the user id and then to verify if they are allowed to run my application. Is this possible? Thank you
There are probably better ways of restricting access to certain transactions within a CICS environment than by grabbing the USER ID and comparing to a list. Most shops have developed standard techniques for restricting access to transactions within CICS. However, if you must find the User Id, try something like this:
EXEC CICS ASSIGN
USERID(WS-USERID)
END-EXEC.
where WS-USERID is a working storage PIC X(8) field.
This is a link to the documentation for CICS ASSIGN.
EDIT
How to check against multiple user ids? You need a list of authorized users to compare the current user id against. If the
user id is in the list, the user is authorized to use the transaction. Typically you have a couple options for managing such a list:
SELECT against a database table containing authorized user ids. Use the current user id as the predicate (eg. WHERE USER_ID = :WS-USERID). If you get a row back, the user is authorized.
SEARCH/SEARCH ALL a WORKING-STORAGE table populated with authorized user ids for a match. If you get a match, the user is authorized.
The WORKING-STORAGE table solution is the least flexible since the program may need to be updated and re-compiled each time a new user is added or removed.
However, as pointed out by myself and cschneid, access security is best handled outside of applicaion programs
using something like RACF or ACF2. Your local systems
administration should be able to help you get this set up.
CICS can talk to an external security manager, such as RACF, CA-ACF2, or CA-Top Secret. Applications are often secured at a transaction level by having the correct rules or profiles in place in the external security manager.
This way, security actions are performed external to the application logic. Access is granted by security personnel and not by an application developer.
To follow on to your comment to NealB's answer regarding multiple users: Your security administrators can add all of the userids in question to a group, and then define access permissions to that group for your transaction.
You really should let your security administration handle transaction access. Good system design puts security management outside of the application.
With CICS TS V4.2 and above with the Security Extensions Feature Pack (integrated in V5.2) you can use SAML assertions coming from distributed applications to provide even more granular access control.
I want to track a user's logon session from the time they login to my site, to the time they logoff.
Is there a pre-existing cookie I should use, or variable? I thought of using ASP.NET sessionIDs but read on StackOverflow that these numbers may change.
I would save my own Session cookie, but I don't want to do something that could be done more efficiently another way. I'm using Windows Identity Foundation (WIF) to handle my authentication layer.
The only cookie I see in fiddler is a FedAuth cookie so I assume that I might be able to derive some valuable information from it, but I don't know where / how in the WIF framework to gain access to such information.
WIF gives a bunch of events you can subscribe to. See these:
http://msdn.microsoft.com/en-us/library/microsoft.identitymodel.web.wsfederationauthenticationmodule_members.aspx
http://msdn.microsoft.com/en-us/library/microsoft.identitymodel.web.sessionauthenticationmodule_members.aspx
You can control some of the cookie characteristic via the config - A Hidden Gem: The WIF Config Schema. In particular, note the cookieHandler section and
hideFromScript - Boolean - default true Controls whether the
"HttpOnly" flag is emitted for any cookies written. Certain web
browsers honor this flag by keeping client-side script from accessing
the cookie value.
In terms of WIF, there is a Deserialize in Tokens.SessionSecurityTokenCookieSerializer and a CookieHandler (Delete / Read / Write) in IdentityModel.Web.