Firebase security rules protect list and public object - security

I have list of servers which has public access only if you have the key value.
Basically if user has object key, then he can retrive complete child object. but he should not be allowed to access list of objects.
Example of the object
{
"servers": { // list of server
// list should not be access directly - no anonymous access
"key1": { // this object can be access anonymously, if user knows the key
"name": "linux"
//...
},
"key2": {
"name": "ubuntu"
}
}
}
How can I make such security rule in firebase for above object?

Simple:
{
"rules": {
".read": false,
"servers": {
"$serverid": {
".read": true
}
}
}
}
Since the root is not readable, /servers is also not readable and only once you have a /servers/$serverid does the read action become valid.
This and many similar topics are covered in the Firebase guide on Security & Rules.

Related

Graph DB Gremlin query for nested properties

I am storing the below data in azure cosmos graph db.
"properties": {
"A": {
"value": "prop1 new value"
},
"settings": {
"DigitalInput": {
"Input1": {
"nTransIn1": {
"tagName": {
"value": ""
}
}
},
"Input2": {
"nTransIn2": {
"tagName": {
"value": ""
}
}
}
When I am trying to query by single property
g.V().has('s_objectId',within('9d8cf5c6-7b5f-4d0b-af70-bf516f219d73')).
valueMap("p_A")
is giving expected output but how to retrieve with property 'settings' which has nested properties. When I try
g.V().has('s_objectId',within('9d8cf5c6-7b5f-4d0b-af70-bf516f219d73')).
valueMap("p_settings")
it is not giving the correct output as the setting property is stored like below in graph database
"p_settings.DigitalInput.Input1.nTransIn1.tagName": [
{
"id": "6057e448-a2e8-48e4-820f-5396003bdcae",
"value": ""
}
],
Your queries and sample data seem to use different field names. It would be helpful if you could add to the question an addV step that creates the structure you are using in a way that can be tested with TinkerGraph.
In general with Gremlin, the way to access map structures is to select your way into it. Something like
valueMap("p_A").select("p_settings")

Azure generate URL for a standard Logic app with connection to CosmosDB

I have a workflow in a standard logic app, that have HTTP trigger. When the workflow is trigged, the workflow, retrieve some data from a CosmosDB. Something like:
The previous method will require to have an API connection. I have already created and deployed a 'V2' API connection. Let's call it myCosmosCon
Also in the ARM template for my logic app I have already added a connectionRuntimeUrl of my connection API (to myCosmosCon) to appSettings (configuration):
....
"siteConfig": {
"appSettings": [
{
"name": "subscriptionId",
"value": "[subscription().subscriptionId]"
},
{
"name": "resourceGroup_name",
"value": "[resourceGroup().name]"
},
{
"name": "location_name",
"value": "[resourceGroup().location]"
},
{
"name": "connectionRuntimeUrl",
"value": "[reference(resourceId('Microsoft.Web/connections', parameters('connection_name')),'2016-06-01', 'full').properties.connectionRuntimeUrl]"
},
.....
]
},
Then I wrote the following in the connections.json:
{
"managedApiConnections": {
"documentdb": {
"api": {
"id": "/subscriptions/#appsetting('subscriptionId')/providers/Microsoft.Web/locations/#appsetting('location_name')/managedApis/documentdb"
},
"connection": {
"id": "/subscriptions/#appsetting('subscriptionId')/resourceGroups/#appsetting('resourceGroup_name')/providers/Microsoft.Web/connections/myCosmosCon"
},
"connectionRuntimeUrl": "#appsetting('connection_runtimeUrl')",
"authentication": {
"type": "ManagedServiceIdentity"
}
}
}
}
Now, when I deploy the ARM template of my Logic app, workflow, ... etc. I see no errors, the workflow looks also good. The only problem is the URL link to the HTTP trigger is not generated, I can't run the program.
However, if I change the connection_runtimeUrl in the connections.json file to have the actual value; to look something like:
"connectionRuntimeUrl": "https://xxxxxxxxxxxxx.xx.common.logic-norwayeast.azure-apihub.net/apim/myCosmosCon/xxxxxxxxxxxxxxxxxxxxxxxx/",
The URL is generated directly and I can simply run the workflow. AFTER that, if I return the connection_runtimeUrl as it was (a call to appsettings()), it still working!! the link also stay there.
It looks like the when I deploy the Logic app and the workflow that the connections.json, do not compile or make the call, so Azure think that there is an error and do not generate the link.
Any idea about how to solve the problem??
Thanks!
Not sure but could be the issue:
When you create a connection api for a logic app standard, you also need to create an access policy at the connection api level for the system assigned identity running the logic app standard.
param location string = resourceGroup().location
param cosmosDbAccountName string
param connectorName string = '${cosmosDbAccountName}-connector'
// The principalid of the logic app standard system assigned identity
param principalId string
// get a reference to the cosmos db account
resource cosmosDbAccount 'Microsoft.DocumentDB/databaseAccounts#2021-06-15' existing = {
name: cosmosDbAccountName
}
// create the related connection api
resource cosmosDbConnector 'Microsoft.Web/connections#2016-06-01' = {
name: connectorName
location: location
kind: 'V2'
properties: {
displayName: connectorName
parameterValues: {
databaseAccount: cosmosDbAccount.name
accessKey: listKeys(cosmosDbAccount.id, cosmosDbAccount.apiVersion).primaryMasterKey
}
api: {
id: 'subscriptions/${subscription().subscriptionId}/providers/Microsoft.Web/locations/${location}/managedApis/documentdb'
}
}
}
// Grant permission to the logic app standard to access the connection api
resource cosmosDbConnectorAccessPolicy 'Microsoft.Web/connections/accessPolicies#2016-06-01' = {
name: '${cosmosDbConnector.name}/${principalId}'
location: location
properties: {
principal: {
type: 'ActiveDirectory'
identity: {
tenantId: subscription().tenantId
objectId: principalId
}
}
}
}
output connectionRuntimeUrl string = reference(cosmosDbConnector.id, cosmosDbConnector.apiVersion, 'full').properties.connectionRuntimeUrl
I'm having trouble with the exact same issue/bug. The only work around as I see it is to deploy the workflow twice. First time with an actual URL pointing to a dummy connection and the second time with the appsetting reference.

404 Error when authenticating a Azure Static Web Application

I have created a static web application in Azure. This is just a plain site with only HTML pages. I am able to deploy and access the application.
The issue is when I try to integrate Azure Active Directory with this service. My staticwebapp.config.json is as follows.
{
"routes":[
{
"route": "/login",
"rewrite": "/.auth/login/aad"
},
{
"route": "/*",
"allowedRoles": ["authenticated"]
}
],
"auth": {
"identityProviders": {
"azureActiveDirectory": {
"registration": {
"openIdIssuer": "https://login.microsoftonline.com/<tenant id removed>",
"clientIdSettingName": "<client id value>",
"clientSecretSettingName": "<client secret value>"
}
}
}
},
"responseOverrides": {
"401": {
"redirect": "/login",
"statusCode": 302
}
}
}
After this, when I try to access any page, it gets redirected to /login and I get a 404 page. I expected it to go to azure authentication page (due to the redirect rule). Are there any other configurations that needs to be done for authenticating a static web application?
One thing to double check here would be the clientIdSettingName and clientSecretSettingName fields.
These are not the actual values, but rather references to SWA settings. Reason for doing it this way is to ensure no plain-text secrets are committed to source control.
So, given literal values
"clientIdSettingName": "AZURE_CLIENT_ID",
"clientSecretSettingName": "AZURE_CLIENT_SECRET"
Azure portal should be set up with something like this:
Documentation clearly mentions this step, but I missed the referential nature of this setting upon first couple of readthroughs. Ultimately, variable names gave it away.

IBM Watson: Missing or invalid for server-side CloudFunctions action call

I went to the Functions/API Key to retrieve the user&password, but I still receive this error:
Dialog node error
Mandatory action property "credentials" missing or
invalid for server-side CloudFunctions action call. The value must be
a string that references a variable such as "$my_creds" that expands
to an object like {"user":"..", "password":".."}. Dialog node:
[GetProducts]
Any ideas why?
// IBM WATSON Dialog:
// Dialog Node Name: GetProducts
// JSON Editor:
{
"context": {
"private": {
"my_creds": {
"user": "*********",
"password:": "*********"
}
}
},
"output": {
"text": {
"values": [
"Product : "<?entities.products[0].literal?>"
],
"selection_policy": "sequential"
}
},
"actions": [
{
"name": "/*****#gmail.com_dev/getProducts2",
"type": "server",
"parameters": {
"url": "<?entities.products[0].literal?>"
},
"credentials": "$private.my_creds",
"result_variable": "context.result"
}
]
}
The credentials need to be present when that dialog node is processed. The context section defines what will be present at the end of that processing. Thus, the credentials are not known to the action.
My advise is to NOT store the credentials in the workspace. This is a security issue and bad practice, even for testing. Follow the example in the Watson Assistant documentation. It has instructions on how to add the credentials to the "Try it out" panel. For production, pass in the credentials from the app or middleware. Here are some examples on how that can be done.

Sync'ing ACL permissions in a NodeJS application using MongoDB

Currently using the Node ACL module from:
https://github.com/OptimalBits/node_acl
This is working a treat but now the requirement is have to reflect any changes to our security config in our ACL layer.
What Im looking for is a clean way to iterate over the roles defined in our security config, decide whether the permissions/resources have changed and if they have update or remove them.
Here is a sample security config file, take the scenario where 'put' is removed from the resource /projectId.
"roles":{
"itemRole":[
{
"roles":"owner-projectId",
"allows":[
{
"resources":"/projectId",
"permissions": ["put", "post", "patch","get","delete"]
},
{
"resources":"/projectId/settings",
"permissions": ["put"]
}
]
},
{
"roles":"collaborator-projectId",
"allows":[
{
"resources":"/itemId",
"permissions":["put","post", "patch","get"]
},
{
"resources":"/api/resource/itemId",
"permissions":["put", "post", "patch","get"]
}
]
},
{
"roles":"spectator-newId",
"allows":[ ]
},
{
"roles":"admin-newId",
"allows":[
{
"resources":"/api/resource/itemId/update",
"permissions":[ "put"]
}
]
}
]
}
The following query will allow me iterate over the different roles and return all the allows for that resources, these allow_* should match what is currently in the security.config:
db.getCollection('authACLresources').find( { _bucketname: {"$regex":"allows_*"}, key: { '$in': [ 'spectator-2bc240c6ffa988260b501922' ] }})
I can then look at the different permissions and compare - just wondering if there is a better way to do this? I know the node ACL module has a method called whatResources but doesn't give you the permissions just the resources.

Resources