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.
Related
The main idea:
I have windows application (maybe IIS site, maybe standalone) that
natively accepts Kerberos authentication and impersonates user.
Kerberos token sent by client to app already has information about
user's groups SIDs, user's SID, etc.
On each request, from
HttpContext.Current.User I get information about user's groups'
SIDs, user SID, translate it to 'plaintext' and pass to non-windows
backend (as header, for example).
Backend (which can not do kerberos)
can read claims added by App from proxied request and send answer, which will be
passed to app and then to user (backend->app->user)
Well, what's wrong with this concept?
Why I can not find any existing apps that can work similar way?
The only thing I found is FASTCGI\CGI, which sets REMOTE_USER variable, but this is not enough - frontend had Kerberos with huge amount of data which is dropped by the way to backend.
I have multiple sub-domains listed in a SaaS app. The app provides options to configure SSO with Onelogin, however it provides the option to Enter only one SAML Endpoint(to which users will be redirected) and One certificate.
In this specific case with Onelogin, the certificate with One login is same across different apps that are setup at Onelogin, however each app has a different SAML endpoint. This makes it impossible to configure SSO with multiple sub-domains of the SAML app.
Tried using SAML Connectors (Advanced) in Onelogin, however when multiple connectors are setup each still has a different SAML endpoint.
Any help in configuring an app in Onelogin using same SAML Endpoint would be very helpful.
You're at the mercy of your SP here. If it only supports one IdP, then there's nothing you can put in place in Onelogin to mitigate that. To extend #todaynowork's answer above, the RelayState parameter might be of use to you but your SP will need to support it. The RelayState parameter allows the SAML request to include the resource your user was initially requesting. When the SAML response is verified at the ACS URL, you can then use the RelayState parameter to redirect the user to their requested resource across any of the subdomains. Assuming your SP side sessions are consistent across all subdomains, that could work for you.
Suggest you use the SP initial SSO. That support deep link. Deep link means you could pass the return url while you do auth request. After success login, it will return to 'return url' you passed.
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.
I have my agent installed in domain 1, and OpenSSO in domain 2, and their is a VPN connection established between the two. So in this scenario will the normal SSO work or CDSSO. I tested and find normal SSO works fine and able to get cookie, but in CDSSO i get 403x error.
You can either configure agent in CDSSO or SSO mode when the resource protected by the agent is located in the same cookie domain ... but it does not make sense. CDSOO is only needed to transfer the SSO tracking cookie in the other cookie domain.
However I suspect you get '#403x' error which is due to agent profile property 'agent root url for CDSSO' does not match the value for 'ProviderID' in the request hitting the CDCServlet.
I have a main website running on AppEngine. It's on a subdomain like main.example.com. This main application is a content portal for our customers. It offers an Ajax application built on YUI. Customers can upload data to it. Users authenticate using Federated Login.
The Ajax application on it allows users to process the data previously uploaded. To do it it should use an webservice running on other subdomain like service.example.com. The webservice does not run on AppEngine but on our services - it's CPU heavy and built on other set of technologies. It would need to download the data on main application - but the downloading service - like everything on the main application - is behind the authentication wall.
I could programatically always allow the service to download wharever it wishes but I think this can turn into a major security problem.
How can I reuse the OpenID authentication "token" to allow it (the service) to appears to the main application as the authenticated user so it can download data? Or If I can do this what would be the best way to accomplish what I intend to do?
You can't really reuse the authentication token. What you should use is something akin to OAuth, though since you control both ends you can make it somewhat simpler:
Generate a shared secret, accessible by both main.example.com and service.example.com
When a user accesses service.example.com for the first time (no authentication cookie), redirect them to main.example.com/auth?continue=original_url (where original_url is the URL they attempted to access)
When you receive a request to main.example.com/auth, first log the user in the regular way (if they're not already). Then, take their user ID or other relevant credentials, and generate an HMAC from them, using the shared secret you established in step 1. Redirect the user to service.example.com/finish_auth, passing the computed HMAC, the authentication details such as user ID, and any parameters you were passed in such as the continue URL.
When you receive a request to service.example.com/finish_auth, compute the HMAC as above, and check it matches the passed in one. If it does, you know the request is a legitimate one. Set an authentication cookie on service.example.com containing any relevant details, and redirect the user back to their original URL.
This sounds complicated, but it's fairly straightforward in implementation. This is a standard way to 'pass' credentials between mutually trusting systems, and it's not unlike what a lot of SSO systems use.