I'd like to use REST protocol with Geoserver running on a web, but when I enter username and password used to log into web interface, I get HTTP ERROR: 401 Full authentication is required to access this resource. Do I need to create separate user with some privileges? May it be webhosting related issue?
Update: I'm able to access existing workspace with web browser, but using QGIS to create new workspace I end up with error mentioned above.
Thank you.
Well I know this is a little late but I will answer it so that hopefully other people with this issue may find it helpful.
The REST process has its own security configuration that needs to be setup in addition to the web interface user. These are different configurations and are setup in different spots. The REST configuration does use that same users you have configured in the web interface it just doesn't use the access rules that you would have set up.
To setup the permissions you need to edit a file in the directory [Geoserver_data}/security called rest.properties.
Please see here and here on what entires to add and edit in this file to provide access to the rest services.
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?!
May u know any possibility to secure access to dashboard of jobrunr? As inside dashboard there are many critical operation can be done, it need be protected with user name and password. At the moment it seems it open for anyone who can access the dashboard's url.
thanks in advance
I don't recommend a setup where the dashboard can be accessed via the internet, I would only allow access via internal IP's.
If you also want to protect for internal IP's, there is a way to do so. Search the issues and the discussions for it (I'm not writing the answer here as I don't like to promote that solution).
Update regarding JobRunr 6
JobRunr Pro 6 will support OpenID Authentication.
I have an application where right now a user could work in different context : in the same client application he could switch his context and work either for a company1 as "Administrator" or if he switch to the second context , he could work as "Editor" for the company2…
This was done by using a custom homemade authorization module, but we are trying to use openid-connect now so we are trying to find some solutions with KeyCloack.
Is it possible to assure the same kind of thing in Keycloack ?
It's possible. BUT it's not something that anyone who doesn't know the internal of your custom implementation could give you a solution.
Authorization services provided by Keycloak is quite flexible and of course complex. I suggest you to take a look at the following link and see which of of authorization solution can answer your requirements and would also be possible to adopt your system to use it (e.g. RBAC, ABAC, CBAC, etc.).
As an example, one solution could be to consider each company a resource and then each user of the application, can have different roles/permissions on each resource. So in Keycloak you define who has what roles on which resources (companies) and then in your app, you check those to see if user is authorized or not. But I'm pretty sure when you get a better overview of the Authorization Services in Keycloak, you would come up with a much better idea.
Keycloak Authorization Services
I want to call external rest resource from within confluence atlassian wiki .
Any examples ?
Can this be achieved via CLI in the backend ?
Please kindly share your thoughts.
The fact that you need this is a warning sign about the design of your app. The plugin api is way more powerful than the REST api and you should lern to use it.
Technically, what you want is possible, but you may have a problem with authentication. When you try to reach the web interface from the backend, you have to log in as a user, you will not be automatically logged in as the backend user. You also need to have access to the url, which is not automatic in corporte environment with all kinds of complex networks solutions.
If the rest service is unauthenticated then you could look to Enable the html-include macro.
Which would allow you to do an html include of the GET REST service call within the page.
Would look like this once enabled:
{html-include:url=http://www.example.com/rest/myservice?param1=1}
However, I suggest looking to use their whitelist feature if you do this.
This also only works for self hosted instances and not for on-demand.
A customer of ours has just purchased CQ5 and would like to externalize all of its security. We'd like to use an STS server for SSO and then leverage a custom authorization/attribute provider instead of the CQ5 repository. Ultimately, we do not want to use LDAP in any way.
Here is how we envision this (some pieces already working):
User browses to CQ5 Dispatcher running in Apache
Apache filter redirects user to STS site where login is completed.
User is redirected back to Apache with SAML Claims.
User ID token is placed as cookie into browser. (everything is working up to here)
CQ5 captures that cookie based on the SSO configuration (working)
Problem starts here: From here, we want to call a custom authorization provider for the user's attributes, roles, groups etc...
We have tried to figure out how to do this and can't seem to find the missing link.
Do we need to create a custom login module? Do we need to create a custom principal provider? Do we somehow use the existing LDAP capability in CQ5 but have it call a custom class which leverages the external auth source?
If anyone here has any idea how to do this, their karma quotient would be full for the year if they could share it. I'm not sure if this is a basic thing you do with JAAS or even where to put my classes after I've created them.
We've worked really hard on this so far and seem to be close, but we keep hitting dead-ends.
Thanks so much if you have an idea where to begin!!
-joe
Recent versions of AEM now include the SAMLAuthenticationHandler which allows you to:
Redirect users to SSO to simulate IDP initiated login, or
Allow AEM to perform SP initiated login with IDP
Specify attributes to take from the SAML Assertion and add to the user's profile node (not sure if you can use this for groups)
Specify which groups users should be added to
Set a cookie called request-path that will store the URL the user arrived at, and then redirect them to that location when they're authenticated (ie. deep linking)
This makes relying on the SAMLAuthenticationHandler better than using Apache to redirect. The current version of the handler bundled with AEM 6.2 does not properly set the cookie when using the redirect method, but Adobe does have an updated version that they can provide that will fix that problem.
I normally recommend that clients do not have their own authentication handlers developed inside AEM.
When not using LDAP, this does create an issue where users will not exist until they've logged in. Additionally, when your architecture includes more than one load balanced publisher, it is possible that a user may exist on one server user synchronization.
Try searching the google group for SSO details. Here's one useful post:
http://groups.google.com/group/day-communique/browse_thread/thread/72c235c83a501252/fba4d08a90487156?lnk=gst&q=SSO#fba4d08a90487156
It seems that you will have to implement a custom LoginModule, more information here: http://dev.day.com/docs/en/crx/current/deploying/custom-login-modules.html