We are needing Wilma PEP Proxy control the access for many applications. I think it is not possible to do yet, with the latest Wilma version. Am I wrong? If I am wrong, how to deal with that?
If I am right, is there some intention to make this possible soon? Now, I am thinking of redirect the PEP response (after token validation) to another application that can do the redirecting job. What do you think about?
As answered in the comments, the PEP is planned to protect just one service. If you need to protect many services in one machine and just using one instance of Wilma, you can do as we did: after the validation of the token, Wilma redirects the request for an application that treats the flow according to the URL, thus redirecting for the right local services.
Related
I want to provide access control at the Orion Context Broker NGSI API level to ensure real data isolation. I want to make sure that a tenant can only query/update their contexts and NOT those of another tenant.
To do so, I started putting an instance of Wilma PEP Proxy in front of Orion Context Broker. Then I configured my own Identity Manager keyrock GE instance based on official IdM Keyrock docker image and my own Authorization PDP GE based on official AuthzForce docker image.
After a few days of configurations and many tries, finally I could have these three security Generic Enablers working fine, authenticating and authorizing requests for the Orion Context Broker NGSI API using PEP Proxy level 2.
However, level 2 of authorization is not enough to ensure what I want, because service (tenant) and sub service (application path) information are in the headers of the request. Particularly in Fiware-Service and Fiware-ServicePath headers. In order to build header-based authorization policies you need to use level 3: XACML authorization.
The problem is that I made some digging in official documentation of Fiware and I could not find any example of an XACML policy. Besides official documentation of Wilma PEP Proxy (see here) says that you may have to modify PEP Proxy source code in order to get this level of authorization.
As this case is thought to check advanced parameters of the request such us the body or custom headers, it depends on the specific use case. So the programmer should modify the PEP Proxy source code in order to include the specific requirements.
It it's that possible?
Do I really have to modify the PEP Proxy source code to achieve something as simple as a tenant can only access his data?
very good question. There are alternative GEis that support perfectly the use cases you are referring to. Please check this presentation
https://es.slideshare.net/FI-WARE/building-your-own-iot-platform-using-fiware-geis
thanks, best
I have a setup with 4 LDAP servers, and I'd like to use the same credentials to authenticate and administrate all of them.
What I had in mind was to use one of the servers to host the credentials, and then setup a referral in the other servers to the server hosting the credentials.
I've done some tests and I didn't managed to authenticate on one of the servers using the "referred" credentials. I believe this is normal but I'd like to be sure I didn't miss anything.
Lastly, if referral do not work, is syncrepl a good candidate to achieve what I'm trying to do ?
Thanks for your help.
Michael
When an application receives an LDAP referral and follows it, it opens a new connection which needs to be authenticated. In other words, if you need to authenticate against all directories, you need to have the credentials in all directories. Replication is the way to make sure the data is identical on all directories.
I am designing a web service which can be used by multiple clients, web, mobile, 3rd party, etc. I am looking at REST as a possible solution and I am considering the case of authentication.
I am trying to keep things simple and performant. For the record, I am using Node.js.
I understand that sessions are not advised for scalability reasons.
What are the opinions of passing username and password on every request over https?
For example:
http://myservice/users/list?username=authorized&password=mypass
Are there severe disadvantages to this approach? Does it open a security hole, cross-site scripting?
Is there a better solution for a web service in general?
You should never use cleartext information inside URL (it can be visible in
browser history, not obfuscated and also inside usual log-pattern like apache).
Instead use HTTP headers for that:
X-USER: user
X-PWD: password
The advantages:
It is HTTP conformant (HTTP headers are used a lot for cross-cutting concerns like security or cacheing control)
In case you use SSL (like through https) the information is encrypted
In case you don't have SSL in place you should use nonce approach. Have a look at HTTP-digest to get some ideas. In case you don't need to identify specific users (like mobile-device end-users) you can completely reuse HTTP-digest.
For security setup reuse as much as possible. It is tough to come up with a custom authentication scheme, because there are many security pitfalls.
You need a nonce.
Otherwise, you should be good if you're using SSL.
Why hello SOers. My question today is about authentication endpoints and the architecture surrounding them.
Most web frameworks and applications I've encountered seem to have a single URL or endpoint to deal with 'authentication' - e.g. processing authentication tokens such as usernames and passwords, and doing something with them.
It seems to me like this causes a lot of follow-on work, like for example if you hit an auth-required URL, the system needs to pass that URL to the authentication endpoint in order to redirect you back there after authentication and authorisation.
Why not simply listen for authentication tokens on EVERY URL endpoint? With a modern MVC framework utilising a PageController or FrontController pattern this should be simple.
Am I missing the downsides of such an approach? Do some frameworks already utilise such a system? Opine me!
Why not simply listen for authentication tokens on EVERY URL endpoint?
Ignoring the word end-pont for a moment, that's what the out-of-the-box Microsoft Forms based authentication does; in the config you specify the parts of the site you want to protect (like the "admin" folder, whatever), you can have as many of these as you like.
When the user hits anything covered by that (as long as IIS pipes it to the ASP.NET processor) they will need to be authenticated (if they aren't already).
I would imagine the ASP.NET MVC works in exactly the same way.
Not sure if that answers your question (?)
I have a set of .NET applications running in a public web environment which connect to a centralized component made up of web pages and web services.
Is there any way to implement a security feature to make the centralized web pages be sure of the caller applications identity? Making a post and supplying a querystring parameter stating the caller application is a naive solution, someone can manually change it.
Any ideas? Tks in advance.
Assign secret keys to each client-server pair and use them to sign messages passed between client and server (using HMAC for example).
TLS/SSL/HTTP. You just need to enable client authentication. SSL is usually only used in the scenario where the server needs to be authenticated. But the server end can be configured to authenticate the client also. Digital certs need to be installed on both ends. This then uses all the appropriate crypto to do the job, ie. public authentication, establishment of secure channel, using Diffie-Hellman, RSA, AES/3DES, whatever you configure.
Take a look at this post. Good place to start.
Another option, perhaps have you look at OpenID?
The current situation:
Servers A, B, and C are trusted and controlled by you. A visitor comes to site A and views a page that sends data to site C, and the data contains something like "origin=A". We're concerned that the user will change that to "origin=B".
A simple fix:
You control all three servers, so let them communicate to verify incoming data. For example, A will change "origin=A" to "origin=A&token=12345", where the token value is random. The user tries to tamper with it and sends "origin=B&token=12345" to server C. C makes a trusted connection to B, saying "Did you send someone to me with token 12345?" B says "Nope" and C knows to reject the request.
This can be arbitrarily elaborate, depending on your needs and whether you're using https. Maybe tokens expire after a certain time period. Maybe they're tied to IP address. The point is that server C verifies any information that comes from the end user with servers A and B.
Are you asking about single-sign-on? (i.e. someone authenticated on AppA should also be able to use AppB and AppC without re-authenticating)
You can do this by configuring the machineKey for your apps so they can share asp.net authentication tokens.
The company I work for currently uses shared forms authentication cookies across the enterprise by using the same machine keys on each web server. However, this is not ideal if you wish to SSO across different domains and it's not very neat for windows app that need to come into the web farm to use the web service methods...
So, where we have to do this we are using SAML
But to clean this all up and make it more unified and more secure we are beginning to implement Geneva
If you communicate with the web services and web pages using http post, you avoid putting the info in a query string.
Send the data over https so that it cannot be tappered with.
You then need to make sure that the call is coming from your public web environment. One way of doing this is to use windows authentication, based on the identity of the application pool.
EDIT 1
Take a look at this link: http://www.codeproject.com/KB/WCF/WCFBasicHttpBinding.aspx
It shows how to set up windows authentication for WCF basic http binding.
Maybe look at the HTTP REFERER field. Under certain conditions this may be treated as reliable. In particular: An A mimic site won't send users from A to C according to HTTP REFERER.