I am kind of new to this field, so please be patient with me.
do I have to have a server side when working with JWT and Box? My original aim was to implement only a simple React/Angular application for my users and issue perpetual tokens for them to use as a kind of a log-in.
It now seems that I have to have some kind of a server that will issue temporal tokens, and use them each time in order to access Box with the client ID.
This actually means that I need to add another authentication layer on top of Box for my users. Otherwise I have to keep private keys and/or other secrets in the JS, which IMHO not quite safe.
Please help me understand if my understanding is correct.
Thank you!
Answer received from Box support:
"You are correct. You will need a server to generate the access token
on behalf of your users. If you do this on the client side, it would
expose your credentials to your users".
we will try do make this work as a Box Integration solution rather then Box platform custom application.
Related
im not sure in what end i shall start this question but basically im lost in the jungle of authentication for my MS Fhir server that i setup in Azure.
What i want to achive is to register a client application that can be "trusted" or authorize user to the fhir server. I have been reading all of the documentation but i just cant get the different pieces together. What i have done so far:
*Register a client application according to this documentation: https://learn.microsoft.com/en-us/azure/healthcare-apis/register-service-azure-ad-client-app. I have troubles understanding how the roles work here.
*Tried to use Postman to get a token by this guide:https://learn.microsoft.com/en-us/azure/healthcare-apis/access-fhir-postman-tutorial but i always get "audiance invalid".
*Switched on the 'Status' under 'Identity' for my application to get a Object Id that i then passed in the Fhir server allowed object Id. Then tried to get a token again. Still "audiance invalid".
Right now i just find my self trying all sort of small things to get this to work with no success. Im thinking of deleting my ms fhir server and start from scratch (again).
My hopes is that someone can help me by simple writing what i need to do and in what order to get this to work, since im obviously to much of a rookie to understand that based on the documentation provided by Micrsoft.
Sorry if my "question" is a bit diffuse, but i have spent hours trying to get this to work with zero success.
Since the problem seems to be the audience perhaps see if maybe this comment could assist you
"If you keep the Audience for the FHIR service as
https://azurehealthcareapis.com then you do not need to create a
separate resource application. That one already exists in your AAD
tenant. If you create a new resource application with the URI of the
FHIR service (and there are good reasons to do that, e.g. to use SMART
on FHIR), then you need to change the Audience of the FHIR service to
match the URI of your app registration. They have to match."
also this
I got it to work by keeping the Audience in FHIR and the URI resource
application consistent - https://[myservice].azurehealthcareapis.com.
Only caveat, the Audience in the FHIR service is read-only. I had to
delete the resource group and recreate.
taken from https://github.com/MicrosoftDocs/azure-docs/issues/38285 and also see another thread that seems to also have a similar suggestion, https://github.com/MicrosoftDocs/azure-docs/issues/30483
So I have the website that provides the API for logging in/registering/etc. And I have the MediaWiki set up at my server.
I need to disallow MediaWiki registration and only allow logging people in through our API. So, when the user tries to login, no request to MediaWiki db for the user should be done, instead the request to our API should be done, logging person in if our API returned the correct data and displaying an error if it didn't.
Is there a way to get it done with MediaWiki?
Thanks in advance.
Your question is very broad and involves some development but also a lot of configuration as well. So, let's start:
First of all, you need to somehow integrate with the API you mentioned, which is possible by developing your own primary authentication provider. See the high level documentation. In this, you will have all the necessary entry points a user might hit when logging in or registering a new account and you can "translate" them to the actual actions which you need to do in your API (which you do not mention what it is or provides, so we can not give you better guidance here).
The second step would then be to configure this new authentication provider as the only one using $wgAuthManagerConfig which will in fact disable all other ways of creating other accounts as well as logging in with other accounts then the ones provided from your API.
If you've more questions, I would suggest that you provide more information and specific points where you're stuck :)
You can have a look at Extension:Auth remoteuser, it could fit at least partly you needs.
I have the gist of how to connect to a MySQL server, however my dilemma is using passwords. Here are some of the things I am looking at.
Architecture will be 1 core service which as of right now will be set up as a digest authentication service. Note: In the future I will also have it set up for kerberos authentication.
The service will have a schema it will need to be able to access in MySQL. Also the micro services will have their own schemas that they will also need to be able to access.
The database will be localhost initially but will eventually be moved (in production) to a separate server altogether.
Given the requirements above, I cannot give the services users that are restricted to localhost and have no password associated with them (nor would I want that in the event the server was hacked). So how can I have access to the database without using any plain text passwords (I don't want it stored in the code)?
Maybe I am just not understanding something here that could make my life so much easier so again I look towards the wisdom of the many here. Thanks in advance!
Some things that I should maybe mention: I plan on using go-martini as my http router, I'd like to be able to set up OAuth Provider, I will need to manage user sessions and authentication (right now not as important as I'm trying to get the core part of the service setup)
Edit: To clarify some information;
I do not have an AD, kerberos, or any other LDAP service to use and would be hard pressed to set them up at this time in a VM I use for development.
The service should not be dependent on any of those items as SSO is a much later requirement in this project.
Strictly speaking it will be deployed in environments where there are none of those available and this is non-negotiable.
I also am specifically developing the services in Go and the clients in React.
Note: I do not need someone to correct MY question. I would appreciate it if you do not change the context of my question to suite the answer you wish to give me. That is not what StackOverflow is about, it is also quite rude to do that. Thank you.
At the moment I am working on a CRUD app that I am going to deploy (someday) and use for my own startup company. However I am nowhere near finishing this product and I stumbled upon a question that I can't seem to figure out.
I am using Express to serve angular the data out of my MySQL database. To do this I had to create '/api/' routes. However if I go (for example) to '/api/clients' I will be able to see the entire list of clients in an ugly array. In this case that does not really matter since it's just the data they were able to see anyways.
However my question is, is it important to block these kind of routes from users? Will problems arise when a user goes to 'api/createClient'? Could this result in a DB injection that could ruin my db?
My project can be found here: https://github.com/mickvanhulst/BeheerdersOmgevingSA
The server-side routing code can be found: server > Dao > clientDao.js
Controllers, HTML & client-side routing can be found in the 'public' folder.
I hope my question is clear enough and someone will be able to answer my question. If not, please state why the question is not clear and I will try to clarify.
Thanks!
Looking at the code, it looks like your URLs can directly be accessed using browser and if yes, then this does pose a security concern.
Doing DB transaction with the user provided fields or values is major security concern, if these data are not validated and sanitised before making a database call.
I would recommend following minimum steps to follow before crafting APIs which is internal but can be accessed using browser -
If this is internal, then do not provide HEADER ACCESS CONTROL from the server or keep it confined only to your domain name. This prevents any ajax call to be made to your APIs from another domains.
Do sanitise and validate all the data thoroughly before doing any kind of database transactions. There are lots of material on this everywhere on how to do it.
If these APIs are meant to be used for internal purpose, then kindly provide some kind of authentication to your APIs before doing the logical work in your routes with the help of middle-wares. You can leverage cookie authentication for very simple API authentication management. You can also use JSON Web Tokens, if you want a more levels of security.
If you are manipulating your databases then I would highly recommend to use some kind of authentication in your APIs. Ofcourse, point number 2 is must.
Hi I have a question regarding security, and web services.
I need a web service to provide an interface for the underlying mySQL database. I am trying to get a Blackberry Application to store data on the web servers mySQL database through a web service.
My question is, how can I ensure that the bb-application is the only thing that is using the web service? The web service will essential insert data into a table. I want to ensure that only the bb-application is allowed to use this service and not someone who figures out the service and starts spamming my table.
Any pointers, best practices or links are greatly appreciated.
Also what sort of web service is best in this scenario?
Take a look at basic authentication over SSL. Configuring the application to include the username/password in the header should be fairly straightforward and the SSL connection will ensure they're not being transmitted in cleartext.
Use net.rim.device.api.crypto.HMAC to implement HMAC authentication and validation. Establishing end to end SSL connections on a Blackberry can be problematic and dependent on wireless provider support unless your users are activated on a corporate BES (which I srongly recommend as part of the solution if you want robust security).
I am going to assume that the BlackBerry application is made by yourself as well. How you can then do this is by creating a sequence or hash that only your application can create, that the web service can verify. For instance, in the beginning of the process, or better, for each step the web service sends down a key sequence, which maps to an internal dictionary within your application on the method to make the unique hash.
The flow would then be as follows:
Perform data task in BB application
Ready to transmit data to web service
Create unique hash from data + your own information from the mapped dictionary
Transmit the data with the key
Web Service verifies the key. If validation fails, it discards the data completely, if succeeds, it will then do what it needs to do.
Continue.
HTH
Disclaimer: Assuming this is an open ended WS.
Also see my answer here.
I would go with a REST web service over HTTPS it would take your problems away. I dunno anything about blackberry apps so I can't give u any pointers on how to use HTTPS in that platform.
If you are creating a SOAP web service then you want to read about ws-security.
Others have indicated using SSL to secure the site. However, that is only one part of the puzzle. Kyle was close with the second, but didn't quite cut it.
The answer is that every single transaction which is posted to your web service must contain some type of authorization key. That key can be pre-shared and baked into the application OR it can be acquired through some other means and set up as part of the application install / configuration process.
Nearly all companies which provide web services online following this method. The idea is that regardless of the underlying protocol (ssl for example) you have to validate that the request is indeed coming from an authorized device / program. Some vendors have the users create a unique key for each user, some for each device, and others just 1 key for the entire organization. Regardless of how deep you take it there is in fact a key.
The key usually isn't that large. It might be anywhere from 15 to 40 alphanumeric characters.