is it possible include one web application into several sso federations
Yes, at least in the SAML-P and WS-Federation protocols there is nothing that forbids this. A web application can inspect the incoming HTTP request (the URL and/or cookies), and use that to choose the STS to redirect to.
However, a specific SSO library/framework might have restrictions in this area.
For example, if your web application is in .NET based on WIF, then the WSFederationAuthenticationModule has exactly one Issuer, which is used for all sign-in requests. (This is usually set in the web.config file in the <wsFederation issuer="..."> attribute). It may be possible to override the CreateSignInRequest() method of this module, temporarily setting Issuer to a different value while the request is created (and applying the proper locking). But WIF was apparently not designed to support this multi-SSO-federation scenario.
Related
Let's say we have a lot of projects. Project1, Project2, etc. and let's say their local development domains are example1.local and example2.local, etc.
Now we have set up a Keycloak instance of our development machine, with a Development realm inside it, with an AdminPanel client in that realm, and we want to use it for all of our projects.
We can manually add https://example1.local/* and https://example2.local/* etc. to valid redirect URLs and web origins.
But this means that we need to add each and every project we have and we do many many projects per year.
We tried https://* but it did not let us login complaining about invalid redirect_uri.
Is it possible to whitelist every domain for Keycloak?
You should be able to do that. I suggest to check your configuration again. Something like this works perfectly for my scenario which is the same as yours. The only difference is that I created a dedicated client for my applications, but still it's single client for many dev environments:
Valid Redirect URIs: https://* or https://*.local
Web Origin: *
Don't put anything extra for Web Origin. Just the * but this is only needed for example if you want to use a swagger-ui hosted on somewhere else. It allows swagger from any domain ask for token from the Keycloak. If you don't put the *, due to CORS error, the swagger-ui or any tools like that would not be able to fetch token.
It's a minor thing, but worth mentioning that you put https:// in the config, so the client app should also be accessed using https. If someone type http by mistake, the same error would be returned.
We tried https://* but it did not let us login complaining about
invalid redirect_uri.
Unless you are working in a testing environment, or you want to get hacked, DO NOT DO THIS in a production environment. From OAuth 2.0 Security Best Current Practice you read an explanation of a an exploit based on this misconfiguration.
Therefore, you should make your registered redirect URIs as specific as feasible, and simply using a wildcard in a big no-no.
But this means that we need to add each and every project we have and
we do many many projects per year.
Wouldn't it be possible to automatize this via scripts or so? Get the project names and then call the Keycloak Admin API to add those redirectURIs to the client?!
I am coding a webapp (E-commerce) for learning purpose using AngularJS + BootStrap and REST.
I have used Apache Wink for REST WS and and application is deployed on JBoss EAP 6.4. My application is working fine.
I can access the back end data using AJAX and webpages are getting populated properly. The issue is security of REST WAS. If I use REST URL directly on browser, without going through front end, JSON data gets populated and my data is exposed. What design changes should i do ?
Please note that initial operation on the website for e.g. browsing the products, adding them to cart etc are stateless. No user's identity is needed for these operations. I still need to secure my data for these interactions. Please suggest, how can I do it.
Sunil
If you want to lock down the services, you may require some type of authentication (for example user/pass) that returns a security token (over https). Then all subsequent function calls may require the security token to be passed in as a parameter (if the operation is sensitive). The token will require a session timeout.
However, if the data is also publically shown on the site, then there's not really a security risk in itself. IOW, how is this any different than them using the public website to get/update data? The rest services usually shouldn't require any additional level of security beyond what is already used on the website to protect the data.
im am currently using a evaluation version of the PingFederate software and reading documentation all the time but still struggling to understand how i can create multiple IdPs for my SP.
I am hosting services, and setting up PingFederate as an SP. Currently in my tests i have one single IdP and all is working fine... I have set up the IIS Agent to intercept traffic and it redirects to my SP to start SP initiated SSO and that all works ok (coming in on the default startSSO url).
However, im struggling to see how i can configure the system for multiple IdP's and was wondering if someone could give a high level overview or point me at some documentation?
I understand that i have to configure the second IdP connection and i somehow need to use the PartnerIdpId URL parameter to distinguish which IdP the user is sent to.... but im not sure where i do that control/configuration for routing to different Idps? Do i need multiple agents on my IIS box that listen on different urls and can then forward the requests themselves to the right SP urls (/startSSO?partnerIdpId=XYZ) within the agent config file?
Thanks for any help,
Craig
I think your question is more around how do you trigger SP-Init SSO for multiple IDPs when using the IIS Integration Kit.
As you've figured out, as the Service Provider, you can create multiple IDP Connections (each with its own unique EntityID). You trigger SP-Init SSO by calling the /sp/startSSO.ping Application Endpoint and pass in the appropriate PartnerIdpId value that matches the EntityID of the IDP you wish to issue the AuthnRequest. You can do this one of two ways -- either hard-code the URL into the IIS Kit pfisapi.conf file so that a single entity is called each time (not the best solution) or you can manually host the URL on a page that isn't protected by the IIS Kit. Unfortunately, a lot of this design decision comes down to how your IIS application is designed and the choice of integration kit.
I would suggest talking through this with your RSA as they can help show you the pros/cons of each integration kit to match up what works best for your application & customers.
HTH,
Ian
PS
I work for Ping.
in SAML 2.0 you can use the AttributeStatement element to provide any kind of application specific information.
What I was wondering, is it really good design to pass business related information within a SAML assertion? Shouldn't this data be provided in a e.g. separate web services call?
I just want to ask for best practice in this case or any real world experiences.
Regards,
Andreas
It depends a lot on just what information you're conveying. For instance, on the application I work on, we use attributes to indicate what web site features should be shown to the user being logged on. That's clearly an appropriate use. Now, we also allow use of attributes to create a user profile, even though we have a web service that does the same thing (and in fact, the implementation calls the web service behind the scenes). It's not an ideal context for that sort of thing; there's no endpoint to convey the web service response to, or any errors resulting from the attempt. But we get a fair amount of resistance from customers, who don't want to have to call a separate web service before they can make an SSO call. So we've had to compromise. What we've done is require that if a customer wants to use this particular functionality, that they provide an endpoint (either email address or web page) to receive errors from the web service call. And if they're concerned about security of the information being conveyed, they can use standard XML encryption.
I've seen many questions about restful-authentication but I'm wondering what strategies are being used to keep browser user agents stateless while authenticating to a RESTful web-service.
Doing it with a custom REST Client is "easy": We can use Basic Auth, Digest, OAuth or roll your own (custom headers, tokens, signatures etc). Thus, for machine to machine we are pretty much covered but I'm only interested in authentication with everyday browser user agents (IE, Firefox etc). For example JSON is out since the browser can not render / use it ;)
Here are some of my thoughts in terms of browser limitations:
AFAICS there is no way for a browser to send custom headers such as those used by OAuth? (Right?)
I have a feeling that one should be able to have a login page (html+ssl for example) where the user does a login. (No Basic auth) The browser then captures a token(s) and passes it back the server with each request. The problem I have with Basic Auth is that I do not have a “nice custom login page”. Is the current authentication mechanism to extensible that we can keep it restful?
I'm careful in breaking / relaxing REST constraints because of the risk of loosing the benefits of scalability.
A similar answer here but I have a special case against cookies : (without going to much detail): The way browsers currently work in using cookies is out of the question since the server is in control of the cookies. ("Set-Cookie" header from server side state). The client does not understand or interpret the contents of cookies it's fed and just returns it. The problems is that the client is not in control of the cookie. Thus, yes we can use cookies in a restful way in "custom/machine to machine clients" but it's not the way browsers implements it.
What strategies and best practices are there that you have been using and what are your experiences? Any extra comments?
I think the browser limitations you mention are essentially insurmountable for most use cases. Our personal solution is to have a lightweight non-RESTful layer presented to the user which contains a custom REST client; for example, for JavaScript apps we expose a server-side REST client via JSON-RPC.
If you are using an apache web server, you might want to take a look at this document.