I'm trying to fulfill a requirement to always have a user be redirected to the same URL after being authenticated through Shibboleth.
At the moment, it will redirect to the referrer (which can change) which we want to ignore and replace it with our own (that never changes).
Update #1
Unsure if I need to do this at the SP or IDP level.
I think we have a similar question, I was searching for an answer to my question when I came across yours. To make sure I have you right, and make this question bump up in the search rankings, you're (likely) wanting to have your SP redirect you to a specific URL after login. What is your Stack setup? Apache?
If you look at the Shibboleth documents - specifically:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionInitiator
and
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPContentSettings
and
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionCreationParameters
you will find that there is a "Location" attribute and a "target" attribute which may meet your needs.
Location (relative path)
The location of the SessionInitiator (when combined with the base handlerURL). This is the location to redirect to when manually initiating a session using the query string protocol.
target (URL) (Version 2.4 and Above)
Allows the resources to return to after SSO to be "locked" to a specific value, even when running as a result of active protection of other resources. In other words, this value overrides the actual resource location when SSO redirection is automatic, including initial access and after a timeout.
In theory you should be able to add these to your configuration. For me I need to figure out how to do this dynamically so if a file is clicked on, after logged in you're re-directed back to it.
we had the same requirement. follow below steps:
You need to make change in your shibboleth idp. you can create one relying party and specify location of it's metadata file. In this service provider's metadata file, there is one attribute named saml consumer. set this value to where you want to point the user after successful authentication.
In our case, we had only one service provider so we created only one entry in relying party and disabled other/default replying parties. after this we added static SP metadata file which contained url of the consumer.
Related
I 'm trying to create a secure spring rest api using pre-authentication security for siteminder.
I 've tried a solution where I 'm getting SM_USER and when I tested it in postman by adding new header SM_USER with random value it seems to work fine.
If you don't provide header I'm getting an error org.springframework.security.web.authentication.preauth.PreAuthenticatedCredentialsNotFoundException: SM_USER header not found in request which is valid.
But how can I be sure that this is secure? if someone knows the URL of my rest api could call this without problem. Should I check something else in spring or only siteminder offers user authentication?
The front-end SiteMinder web agent is the guaranty that the session is valid - you must make sure via server/network configuration that your application cannot be accessed directly without first passing through the SiteMinder web agent.
Also, SiteMinder asserts multiple headers. SM_USER should not be used alone because it can be asserted by the web agent in some circumstances when the user does not actually have a valid session. Instead, you should first look for the existence (non-blank) of SM_SERVERSESSIONID, which only exists if the session is valid.
Lastly, I generally try to avoid SM_USER at all - because SM_USER is actually not a user attribute at all, but rather is "the login identifier used for authentication". If SiteMinder authenticates users via federation (e.g. SAML) or x509 authentication, SM_USER will be rather different than if a login form was used. Instead, its better in SiteMinder to set a "universal id" that is a user attribute, and appears in the headers as SM_UNIVERSALID. Your SiteMinder administrators will know how to do this (and may already have - look to see if you have a SM_UNIVERSALID header available already).
One other caution, in some SiteMinder configurations, the underscore will not be in the header name (use of the underscore is called "legacy" header mode in SiteMinder), so you might want to make your app configurable with respect to the header names, e.g. SMSERVERSESSIONID, SMUSER, SMUNIVERSALID etc.
If you want to programmatically re-validate a session, you can use the SiteMinder Agent API or REST API, or look at my company's product "SSO/Rest" which provides a comprehensive set of uniform REST interfaces to SiteMinder and also other SSO providers (http://www.idfconnect.com).
HTH!
-Richard
I have a requirement where application needs to secure URL for users based on the role user is having and parameter passsed..
Eg:
There are four roles
PREVIEW_VIEW, PREVIEW_MODIFY, PUBLIC_VIEW, PUBLIC_MODIFY
And URL hit is
http://myapp:8080/console/editGroups.action?orgId=1&recipientType=PREVIEW
Lets say User is having only 'PUBLIC_VIEW' and 'PUBLIC_MODIFY' permission.
If user is passing parameter 'recipientType=PREVIEW' then page should be accessible only if user is having 'PREVIEW_MODIFY' permission.
So how to secure URL and parameter together?
i.e Allow this URL(http://myapp:8080/console/editGroups.action?orgId=1&recipientType=PREVIEW) only if user is having PREVIEW_MODIFY permission
and
allow this URL(http://myapp:8080/console/editGroups.action?orgId=1&recipientType=PUBLIC) only if user is having PUBLIC_MODIFY permission
Thanks
Chetan
to me, this is the wrong way of proceeding. URLs are changable by definition by the client because it's the client itself who decides who or what to call. Therefore, URLs are the worse place to put security information. Besides, if you need to walk this way, I think you can't but leverage encyption.
The server is the one to decide which role(s) the client is associated to, therefore it forces the client to include a parameter with its roles combination. Of course, this MUST be encypted (symmetric encryption will be enough) since the client MUST NOT be able to alter it in anyway.
When the client performs the request, the server retrieves the encrypted attribute and decrypt it to obtain the client's roles.
If you need to make this attribute understandable, you could show it in clear and use an additional cryptographic HASH parameter.
I have configured Local STS with my web application (which is hosted in IIS 7 and has the host name as www.abc.com) and it can receive the claims from the STS and it can login. Now I have added another host name (www.xyz.com) to my web application. If user a login to a page in the application using www.abc.com/page1 and it redirects to local STS and it authenticates the user and adds the security token. Now if the user visits www.xyz.com/page2 it also redirects to the STS for authentication.
If a user either logged in www.abc.com or www.xyz.com they need to access the other domain page with out login. Is it possible? How do we achieve this?
In broad strokes, if you have two different relying parties, each needs to route the user to the IDP. If the IDP is configured for single sign on, the user will only notice the routing to the IDP the first time. On the second routing, (assuming same browser session and that the routing is within the lifetime supported by the IDP) the user will be authenticated without seeing a page at the IDP and being required to present credentials.
So, part of your answer hinges around what you mean by login: if you mean "experience a challenge and enter credentials" by log in, you should be able to enable this by simply ensuring that the IDP is configured for single sign on.
On the other hand, if by login you mean the redirect to the IDP, then you need to make sure the application is able to share state across the different page names. Note that usual management of state is via cookies, and note that a cookie for abc.com will not be returned to a web page named xyz.com. There are a number of clever ways to resolve this, although i am not aware of any simple application configuration solutions. One example is to have some part of both the abc.com page and the xyz.com page accessed by the url shared.com. State cookies can then be set by the shared.com transaction when logging into abc.com and read by the shared.com transaction when subsequently accessing xyz.com.
I've never had to implement such a cross domain cookie solution and have only had off-hand conversations with colleagues about it: we've always found the silent redirect of single sign on to meet our requirements. Careful research into the privacy impact of such a solution and the likelihood that such cookies might be blocked should be considered before development.
Is it possible for SiteMinder to inspect a cookie (not the SM_) set by my application, for a value and if it matches a particular value, allow access to a resource?
For example, if my application sets a cookie back to the client with FOO="kjfkjafbf3nd" is there a way on subsequent requests (with that cookie submitted back to the server) for SiteMinder to see it and do something with it, like compare it against a value, or part of the resource URI, etc and perform an action (allow or deny access)?
I am not sure that is possible, in any case this does not seem like a good idea. Since SiteMinder is the first line of protection it should not need to depend on the applications behind it for decisions.
If your application has some authorisation logic and you would like to use that through SiteMinder the correct way would be to use SiteMinder authorisation. You could look at using a different Az directory or use the ActiveExpressions/Active Rules etc.
By default, when the user submits the login form, and is authenticated, he is redirected to the last URL he wished to access, before he logged out (fetched from the request cache) or to the root URL. Additionally, if a 'spring-security-redirect' parameter is found with the form submission request, we are redirected to the value of that parameter.
I wish to use this feature, but in this thread, Luke Taylor mentioned that it would be a security risk, and we should use an additional form field for that purpose, and then customize our LoginSuccessHandler to retrieve and use that form field as we wish.
I am not able to understand the security risk he mentioned, and the reason we should not use a feature that Spring Security has already provided, instead of using our own custom logic. My reasons for wanting to use the functionality are the same as that of the OP in the above thread.
The Attack behinde is some kind of Cross-Site Request Forgery (CSRF-Attack)
If an Attacker (A) send an modified link to Some Person (B) and B have a short look at this link and see it is your application, he might click this link.
Person B enters his credentials and get looged in.
But now the redirect is executed, WITH THE CREDENTIALS OF THAT PERSON B!
So imagine you have an Application where each User can Spend some money by invoking http://yourApp/spendSomeMoney=100 -- (The first fault in that application would be that this is a GET and not a POST)
Now imagine (A) send (B) this link:
http://yourApp/login.jsp?spring-security-redirect=http://yourApp/spendSomeMoney=100
You see the problem.
In general I would stongly recommend to use some CSRF protection filter, no matter I you use that redirect or not.