I have AWS Cognito based auth implementation on a Node App (Server-side, not using Amplify.
I have been using adminInitiateAuth with AuthFlow ADMIN_NO_SRP_AUTH and it gives SOFTWARE_TOKEN_MFA in ChallengeName for MFA which is working well.
Now I need remember/trust this device functionality.
For that, once I send DEVICE_KEY in adminInitiateAuth, I get DEVICE_SRP_AUTH as challenge.
I have tried using adminRespondToAuthChallenge
adminRespondToAuthChallenge({
ClientId: clientId,
UserPoolId: UserPoolId,
ChallengeName: 'DEVICE_SRP_AUTH',
ChallengeResponses: {
PASSWORD_VERIFIER: "PasswordVerifier-used-when-doing-confirmDevice",
USERNAME: "user-id-for-srp",
DEVICE_KEY: "device-key"
}
})
I get SRP_A is required error message. I am not quite sure how to get SRP_A in there and now I am not sure it it is even right way to do remember this device functionality
I was hoping if I get through this, it will skip MFA and give me auth tokens that I need.
Can anyone guide me through this.
Related
After testing authentication in Orion with keycloak (Orion APIs authentication through Keycloak) with kong-pep-plugin, I'm interested in the authorization too; in particular, I want to give specific permissions (on path and verb) to users/groups like I used to do with AuthZForce.
Could you help me?
Thank you
sorry that I only see your request right now. This is very much tied to configuring Keycloak, but it is possible, yes. The kong-pep-plugin delegates all decisions to Keycloak's Authorization Serivces and just takes its decision. Thus, you should read the documentation on that: https://www.keycloak.org/docs/latest/authorization_services/index.html
An example (declarative)configuration for allowing different groups to access different paths can be found in the integration-tests:
https://github.com/FIWARE/kong-plugins-fiware/blob/main/it/src/test/k3s/keycloak.yaml#L518-L567
Another, better readable, example is our demo environment:
https://github.com/FIWARE-Ops/fiware-gitops/blob/master/aws/fiware/keycloak/templates/realmConfigMap.yaml#L139-L203
This combination of resources and policies allows the group "consumer" to access the path "/keycloak/ngsi-ld/v1/", while the group "admin" can also access "/keycloak/".
The authorization services allow for much more fine-grained and powerful configurations, so I really recommend the official documentation on it.
Best
As an addition for the GET/POST question:
Thats something you can implement with the javascript policies feature from Keycloak(keycloak.org/docs/latest/authorization_services/…). The kong-plugin forwards the http method as "http.method" claim(see github.com/FIWARE/kong-plugins-fiware/blob/main/kong-pep-plugin/…)
An example policy could granting access only for GET requests could look like:
var context = $evaluation.getContext();
var attributes = context.getAttributes();
var method = attributes.getValue('http.method').asString(0);
if (method === 'GET')
{$evaluation.grant();
Combining a resource policy with such a js-policy would give you the access-control you want.
I have an app which interacts with the database directly with mysql1 library like the example below:
Future FetchData() async {
final connection = await MySqlConnection.connect(ConnectionSettings(
host: 'mysql-hostname.example.com',
port: 3306,
user: 'root',
password: 'root',
db: 'testDB',
));
var results = await connection.query('SELECT * FROM `testTable` WHERE 1');
for (var row in results) {
print('${row[0]}');
}
// Finally, close the connection
await connection.close();
}
I wonder if this is a safe and secure method. Because when I build the app I pack all the information (username, password) about connecting my database in the app. Is this risky so should I use a separate back-end for this kind of tasks?
It is generally safer to put a trusted backend environment between your database and app. But even in this case you will have to ensure that only your app has access to this backend resource.
For example if you use Firebase as backend, there is an AppCheck service available. Although this is relatively new, it can attest your app's authenticity.
If you prefer to do it on your own, you can create a bearer token that your app will add the the requests, preferably in the request's Authorization header, and check it in the backend before accessing protected resources. But then the question remains, where do you store this bearer token safely.
If you want to keep it in your code, you should properly obfuscate the code before uploading it to the app stores. Even in this case it is a good idea to check for rooted or jailbroken devices to prevent misuse, for example check out flutter_jailbreak_detection.
There are also secure storage packages, which can store sensitive data in a safer way. Unlike SharedPreferences, these can mitigate the risks of unauthorited access to your secrets. See flutter_secure_storage for example.
It really depends on the level of security that you are looking for. Are you storing user-generated sensitive information in your database? Then the answer is that you should ideally not store that information in your code nor should you ship your application with that information bundled inside it.
I highly suggest that you start using Firebase for your usage. Firebase is an absolutely fantastic and free product provided by the Google, the same company behind Flutter, and within a few minutes you can build a whole experience that relies on authentication with Firebase and you can safely store user-generated content in Firebase.
We have been directly using U2F on our auth web app with the hostname as our app ID (https://auth.company.com) and that's working fine. However, we'd like to be able to authenticate with the auth server from other apps (and hostnames, e.g. https://customer.app.com) that communicate with the auth server via HTTP API.
I can generate the sign requests and what-not through API calls and return them to the client apps, but it fails server-side (auth server) because the app ID doesn't validate (clients are using their own hostnames as app ID). This is understandable, but how should I handle this? I've read about facets but I cannot get it to work at all.
The client app JS is like:
var registerRequests = // ...
var signRequests = // ...
u2f.register('http://localhost:3000/facets', registerRequests, signRequests, function(registerResponse) {
if (registerResponse.errorCode) {
return alert("Registration error: " + registerResponse.errorCode);
}
// etc.
});
This gives me an Error code 5 (timeout error) after a while. I don't see any request to /facets . Is there a way around this or am I barking up the wrong tree (or a different forest)?
————
Okay, so after a few hours of researching this; I'm pretty sure this fiendish bit of the Firefox U2F plugin is the source of some of my woes:
if (u.scheme == "http")
if (url2str(u, true) == url2str(ou, true))
return resolve(challenge);
else
return reject("Not matching appID");
https://github.com/prefiks/u2f4moz/blob/master/ext/appIdValidator.js#L106-L110
It's essentially saying, if the appID's scheme is http, only allow it if it's exactly the same as the page's host (it goes on to do the behaviour for fetching the trusted facets JSON but only for https).
Still not sure if I'm on the right track though in how I'm trying to design this.
I didn't need to worry about facets for my particular situation. In the end I just pass the client app hostname through to the Auth server via the secure API interface and it uses that as the App ID. Seems to work okay so far.
The issue I was having with facets was due to using http in dev and the Firefox U2F plugin not permitting that with JSON facets.
I've achieved a successful WebRTC connection using Firebase - but it only works if both users are on the same local network. I've tried using using different STUN servers, and even used TURN, but with the same result.
Is there any sample code or any place which shows how to achieve basic signalling for WebRTC using Firebase? I've tried looking at the docs, and there doesn't seem to be. What confuses me more is that my app works in the local network, but not outside of it.
Btw, I've also used PubNub and I've no problem using that to achieve signalling (even across networks).
I've set up a reference to my data like this
myDataRef = new Firebase('https://<myapp>.firebaseio.com');
myDataRef.on('value', function(snapshot) {
var json = snapshot.val();
and I communicate messages like so:
myDataRef.set(json);
The json message will include the action type (candidate, or offer or answer) and will also include the SDP, if required.
Any help on this will be appreciated!
I was wondering if Wirecloud offers complete support for object storage with FI-WARE Testbed instead of Fi-lab. I have successfully integrated Wirecloud with Testbed and have developed a set of widgets that are able to upload/download files to specific containers in Fi-lab with success. However, the same widgets do not seem to work in Fi-lab, as i get an error 500 when trying to retrieve the auth tokens (also with the well known object-storage-test widget) containing the following response:
SyntaxError: Unexpected token
at Object.parse (native)
at create (/home/fiware/fi-ware-keystone-proxy/controllers/Token.js:343:25)
at callbacks (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:164:37)
at param (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:138:11)
at pass (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:145:5)
at Router._dispatch (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:173:5)
at Object.router (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:33:10)
at next (/home/fiware/fi-ware-keystone-proxy/node_modules/express/node_modules/connect/lib/proto.js:195:15)
at Object.handle (/home/fiware/fi-ware-keystone-proxy/server.js:31:5)
at next (/home/fiware/fi-ware-keystone-proxy/node_modules/express/node_modules/connect/lib/proto.js:195:15)
I noticed that the token provided in the beggining (to start the transaction) is
token: Object
id: "%fiware_token%"
Any idea regarding what might have gone wrong?
The WireCloud instance available at FI-WARE's testbed is always the latest stable version while the FI-LAB instance is currently outdated, we're working on updating it as soon as possible. One of the things that changes between those versions is the Object Storage API, so sorry for the inconvenience as you will not be able to use widgets/operators using the Object Storage in both environments.
Anyway, the response you were obtaining seems to indicate the object storage instance you are accessing is not working properly, so you will need to send an email to one of the available mail lists for getting help (fiware-testbed-help or fiware-lab-help) telling what is happening to you (remember to include your account information as there are several object storage nodes and ones can be up and the others down).
Regarding the strange request body:
"token": {
id: "%fiware_token%"
}
This behaviour is normal, as the WireCloud client code has no direct access to the IdM token of the user. It's the WireCloud's proxy which replaces the %fiware_token% pattern with the correct value.