I have installed OpenAM in domain 1, and my application is in domain 2 protected with J2EE agent,My question is, Once I get access to my application after authentication do the agent contacts over the network to openam(for authorization), for every click I make on my application,If the answer is yes than what will be the performance impact if my agent and openam is in two domains which are geographically separated, If the answer is no,how does an agent invalidates an access to my application,when admin invalidates a user session from openAm home page.
The agent needs to communicate with OpenAM for authorization decisions, but it will cache the resulting decision so subsequent evaluations will be local.
OpenAM can call back the agent in the container (that is what agentapp.war is for). This can be used to notify the agent that the users session is no longer valid. For example, if they logged out of OpenAM, or their session expired.
The performance impact will be very small. OpenAM is supporting installations with tens of millions of users - so unless your site is very large this will not be an issue.
You generally want to localize the agent to OpenAM traffic to the same data center when possible. If you had multiple regions you would want to have OpenAM instances in those regions. They can be configured to fail over to each other if required.
By default OpenAM and J2EE Policy Agent communicates in Notification mode so OpenAM would notify (check notificationUrl field in config properties) an agent for any Logout events. Now, as mentioned by #warren-strange a J2EE Policy Agent periodically sends request to OpenAM server and that way it would be able to know if Token exists and is valid.
Related
I was wondering how the amlbcookie and sticky sessions works with the policy agents, specifically in a CDSSO environment.
I understand that in a regular SSO implementation, where the protected application, and therefore the web agent is in the same domain as the OpenAM deployment, the web agent would have access to the amlbcookie and can read the value or just pass on the cookie to OpenAM during session validation.
However, how does this work in a CDSSO situation? In this case, the policy agent does not have access to the amlbcookie since it is in a different domain (the OpenAM domain). I understand that the policy agent will read the session id from the LARES POST.
Is the amlbcookie value passed as well in the LARES POST? Is this what the com.sun.identity.agents.config.postdata.preserve.lbcookie property is for?
After doing some research, and working with the vendor, I learned that right now, policy agents do not pass on the amlbcookie in the CDSSO workflow. There is a bug open for this at the following link:
https://bugster.forgerock.org/jira/browse/OPENAM-2396
However, the authoritative server that issued the token will store its server id as part of the session value.
http://blogs.forgerock.org/petermajor/2015/08/sessions/
The Policy Agent will extract the server id from the token, and can create the amlbcookie, or the OpenAM server can read the authoritative server id from the token.
So, there is no need for the LARES post to also pass the amlbcookie, since all the information required to derive it is in the session token.
I was trying to register an Application Login Module in Websphere but I don´t find any easy example in web.
There are a lot of IBM documents, but too much complex, and I can´t figure out how to register an Application Login Module.
I already have success with a System Login Module bounded to WEB_INBOUND, it works, but affects all my system. I want a Login Module to serve only my applications web, with JAAS authentication.
I´ve tried to bound a login module to existing WSLogin but it doesn´t seems to be working.
Any help ?
tks[]
You need to setup security domains to get the separation you are looking for wrt to the login configurations. The security framework uses the WEB_INBOUND login configuration to authenticate the user for all web applications irrespective of adminConsole or user applications. When you create a security domain and customize the WEB_INBOUND configuration at the server/cluster domain level, it will be used for all the user web applications deployed in those processes. You need to setup the multidomain in a cell topology and assign the domain to the server/cluster where you applications are deployed.
Once you setup the domains, the WEB_INBOUND configuration at the server/cluster domain will be used by the user applications hosted in that server/cluster while the WEB_INBOUND configuration at the admin/global domain will be used for the adminConsole application at the Deploymener Management process where it is deployed.
The application JAAS login configurations are meant to be used by the applications directly. One can create an application login configuration and programmatically use it in the application to perform direct login -
LoginContext lc = new LoginContext("myAppLoginCfg1", callBackHandler);
I asked around and this is the answer that comes from the owner of container security:
The WEB_INBOUND is a JAAS system login that is always configured by default. However, you can specify your own JAAS application login or customize the existing WEB_INBOUND system login. If you want only one application to use a different JAAS login from all your other applications, you can use a security domain that has those different security configurations. The only catch is that application server has to be in a separate server from the other apps. That way, you can map your security domain to that server.
Here's an info center article about security domains:
http://www-01.ibm.com/support/knowledgecenter/#!/SS7K4U_8.5.5/com.ibm.websphere.zseries.doc/ae/tsec_sec_domains_config.html?cp=SS7K4U_8.5.5%2F1-8-2-33-1
And one on application logins:
http://www-01.ibm.com/support/knowledgecenter/#!/SS7K4U_8.5.5/com.ibm.websphere.zseries.doc/ae/rsec_logmod.html?cp=SS7K4U_8.5.5
And system logins:
http://www-01.ibm.com/support/knowledgecenter/#!/SS7K4U_8.5.5/com.ibm.websphere.zseries.doc/ae/usec_sysjaas.html
And here is a much more practical answer that comes from the security dev lead:
So an additional question is - why would you want to do that? Do you want to do anything specific for just one app during login that you do not want for other app logins? (I would think so) You can get the app name in your custom login module and can use that to provide your own app based login requirement in your login module (or skip it) if needed.
Me: Ya, this is what I would do. You can also implement this based on what is in the request. I did one where it would request a SAML token from an STS and put it on the runas subject if I could tell that the request came from WebSeal (and not if it didn't).
If what you need to do for the 'app-specific' case requires skipping what is done in ltpaLoginModule and wsMapDefaultInboundLoginModule (that should run for the other apps), you can't really do that. However, you can modify their behavior.
Read through the task I've given a link to below. Yes, I understand it is a WS-Security task, but its about using APIs. You'll get what I'm talking about if you read closely, particularly the 3rd ("When a caller...") and 5th ("To use a..") paragraphs. The parts that you should be concerned about in the code is the WSCREDENTIAL* stuff.
http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twbs_config_wssec_caller_no_reg.html
I have been working on IBM Maximo Anywhere apps such as Work Approval and Work Execution for sometime now have few queries regarding the login mechanism used by these apps. To be specific as per my understanding anyone having access to maximo on that particular environment can login into the anywhere apps - is that a correct statement? and if yes then how does it work in a disconnected state? If for any reason maximo is down will it mean that the app will not be able to authenticate a user and hence unable to login as well? And alongwith that is there any other kind of authentication done for example LDAP etc? Are there any different kinds of login failure messages that are displayed depending on why the app isnt able to let the user login? or is it a common one saying "Login Failed"
The first time the user ever logs into the application, they do have to have a connection to the Maximo server to authenticate. We also validate that the user is authorized to use this particular mobile app. We have a security group for each mobile app that the user must be a member of. After the authentication and authorization finishes, we download, store, and sign the locally stored data with the username/password combination, so that on subsequent login attempts, if the server is down, we can fail over to the locally stored data. This also guarantees that the locally stored data is protected.
We support all of the types of authentication configuration that base Maximo supports.
More information here:
http://www-01.ibm.com/support/knowledgecenter/SSPJLC_7.5.0/com.ibm.si.mpl.doc_7.5.0/security/c_authentication.html
we have deployed a OpenAM V10 cluster with two nodes and sometimes and several SPs configured. When a user logs into the system, the systems validates its credentials and starts the user session but sometimes it seems to "cross" the session with one from another user whom is already logged into the system. After that, when the user tries to access any of the registered SPs an error is shown and it's forced to be logged again. So, in fact, it's not really a security problem but it's not cool at all.
We really don't know if the problem is in OpenAM or in the load-balancer.
Any idea is welcome.
OpenAM does not use HTTP session but it's own session id which is cryptograhically secure, so it's very unlikely there is a SSO session ID clash.
It's not clear what "cross the session" really means ... a session in you app? Then it's an application issue, not an OpenAM issue.
It will never be an LB issue.
Do the session management between openAM and protected application work's in CDSSO environment. Because I find that in CDSSO setup if I invalidate a session in openam side, it still remain active in application side.
You either have to ensure that notification mode for the agent, protecting the app works, or use polling mode for the agent, but minimal polling mode is 1 minute. So users can access protected pages for another minute after you invalidated the session on OpenAM.
Also be aware what polling means which regard to number of requests to OpenAM infrastructure.