I have noticed that some built-in Azure policies use "Microsoft.Security/complianceResults" for auditing. For example, the "The NSGs rules for web applications on IaaS should be hardened" is using "unprotectedWebApplication" from "Microsoft.Security/complianceResults".
Where can I find the compliance rules available in "Microsoft.Security/complianceResults"?
Can I use this to define my own policy rules?
The only field aliases that I can find for compliance results is Microsoft.Security/complianceResults/resourceStatus. You can use that to check the resource status for the type compliance Results. To see the rules that I had, I used the vs code extension by policy because it breaks down the resources and you can see the alias. If you want to see all the available rules, it would be through Azure Security center.
Related
I have two set of RestAPIs used for same application developed on two different frameworks.
One on SpringBoot secured using OAuth 2. Second set of APIs developed on Jooby microframework of RestAPIs.
Since the services on Jooby are not secure how can i do that? So that both set of APIs are secured.
The Login is working in conjunction with SpringBoot App and OAuth 2.0 and same user credentials should be used for jooby apis as well. Does it make sense to put some sort of gateway common for both the set of apis?
Well, security is a broad topic and frameworks implement security guidelines and support when becoming mature. Even I don't have any prior experiences with Jooby, after referring their documents I found a couple of support libraries and extensions.
Moreover, you can follow this great Github repo as a checklist and implement what relevant to your context.
If you can provide more implementation details about your login, I can give a more specific answer. But it seems common gateway isn't really necessary and you can use authentication credentials such as tokens directly with your Jooby API's as well. See pac4j which is listed under Jooby documents.
With the traditional OAuth API, I can specify the ?hd=<domain> parameter to limit logins to specific G Suite domains. I'm unable to find a way to do this with the googleyolo auto sign-in API.
Is this supported or am I just not able to use the API at this time?
I'm the product manager at Google for this library. This is a good feature request and we have it on the roadmap but no timeline yet. I'll update this answer when it's available, but we've got a ton of great feedback and requests from developers around this library so it might be some time to work through the backlog.
Currently in Hyperledger Fabric 1.0 there is a central membership service. I want a way to make it decentralized so that atlas 50% of the members have to agree for a new member to join the network. How can I achieve this?
The idea is basically put the membership logic in chain code and let member service fetch data from chain code at the time of enrollment. But how to enforce this, I mean how do we know that membership service is actually reading from blockchain and not cheating.
This is actually natively support by Hyperledger Fabric, and the behavior you describe is actually the default for channel membership changes.
Each channel begins life with a genesis block. The contents of this genesis block define the channel members, as well as policies for which users from these organizations are authorized to perform different functions on the blockchain. For instance, some users may be allowed to submit transactions, but not read the whole blockchain, while others could do both.
To change the channel membership, you submit a channel reconfiguration transaction. This transaction specifies the new membership, and must include enough signatures to authorize this modification. By default, this is signatures from the admins of a majority of the organizations.
The policy framework is actually quite powerful, and with a little knowledge, you can define even more powerful rules. For instance, you could require that OrgA and 3/10 other organizations sign off to change membership. Or, you could require that all but one Org agree to make any membership change, or an infinite number of other permutations.
Some links you might find helpful:
http://hyperledger-fabric.readthedocs.io/en/latest/configtxgen.html
http://hyperledger-fabric.readthedocs.io/en/latest/policies.html
http://hyperledger-fabric.readthedocs.io/en/latest/configtx.html
The documentation and tools around reconfiguration are a little lacking at the time of this writing. The most useful place you can probably look is:
https://github.com/hyperledger/fabric/tree/release/examples/configtxupdate
There are two protobuf structures you must familiarize yourself with, the common.ConfigUpdate, and the common.Config. Channels are created by submitting a signed config update to the ordering service, which generates a corresponding config embedded in the genesis block.
The policy which governs membership changes for a channel is specified as the mod_policy field of the Application group, which is a subgroup of the Channel group. This field defaults to Admins, which refers to the policy definition Admins within the Application group. By default, this policy is set to MAJORITY of the Admins policies for the organization groups defined under the Application group.
So, to modify this policy before creating your channel, you would decode the configtx to JSON using the configtxlator tool, make your modifications, and then encode it back using the configtxlator tool once again. Submitting this new transaction will create the channel with the policy you specified.
If you wish to modify membership after the fact, the process is similar. Retrieve the current channel configuration, decode and modify it, then use configtxlator to compute a config update structure which represents your change. Gather signatures via peer channel signconfigtx then submit it to modify your channel's configuration.
This process is obviously all a bit manual at the moment, but in the future, common tasks should be automated by the SDKs and the tooling should improve as well.
Note: configtxlator is a REST service so that it can be accessed conveniently from inside your SDK application, independent of language.
As a quick addendum. You asked how you can be sure that no one is 'cheating' and not really getting the required signatures. This is also built into the system. All changes to the channel configuration are validated not only by the ordering network, but by all peers in the system. If a configuration arrives which cannot be validated, then all nodes in the network will notices, and will halt usage of that channel until corrective administrative action is taken.
For decentralised membership, that is not dependent on a centralized CA, take a look at Blockstack.
Assumptions:
Multiple SAPUI5 apps are build
they should be deliverable (via SAP transport system, potentially over transport files) into different clients
technical steps to create roles and launchpads are known
a SAP namespace is registered and available
Question:
Is there any guide to design the launchpads/roles for these apps especially to make it deliverable to different customers?
There are guidelines in the FLP documentation.
This documentation describes how to create your own Fiori Launchpad content, such as catalogs, groups, and so on. Delivery however differs depending on whether its ABAP on premise, HCP, the delivery channel, and so on.
I am currently setting up an ASP.NET MVC application that will be hosted on the Windows Azure platform. The application may be used by hundreds of third parties, each with their own group of individual users, which will need to be authenticated by logging in. I am looking at using Windows Azure Active Directory (WAAD) for the authentication piece.
Obviously I can use WAAD to set up individual logins for each user, then add them to a group which has been set up for the third party they belong to.
This will likely be sufficient for most third parties. However, some may already have their own Active Directory (AD), which may or may not be a WAAD, with all of their users as members. I am wondering if there is a way that I can, relatively easily, provide a way for them to connect their Active Directory to my WAAD, allowing their directory users to authenticate with our WAAD.
I have read about integrating an on-premises AD with WAAD, either through synchronisation or using a federated login. However, all of the articles seem to be aimed at "your" on-premises AD linked with "your" WAAD. Obviously since you manage both directories there is inherent trust there. However, for obvious reasons, I only trust third parties to authenticate their users and do not want to open up a mechanism where they may be able to manage my WAAD and affect other people's users or groups.
So...
Can I connect a third party AD with my WAAD and let them authenticate their users for my application, without compromising the security of my WAAD?
If so, what is the best way to configure this set-up? Would I use the standard federated services software, for example, or is there something more suitable?
1) You can definitely expose Azure AD applications to users from other Azure AD tenants, without the need to manage their directories or give them any access to yours. The Azure AD documentation refers to those kind of app as "multi-tenant". You can find a detailed example in https://azure.microsoft.com/en-us/documentation/samples/active-directory-dotnet-webapp-multitenant-openidconnect/.
2) multi-tenant applications operate under the assumption that all the participating directories have their corresponding Azure ADS tenant. That is the case when, for example, they did set up Office365 or any other cloud service. Direct federation would not work in this scenario, given that the just in time provisioning of apps and the enforcement of permission and access rules relies on the directories and users being stored in shared infrastructure (though still completely isolated form each other, as is always the case in sound multitenant systems).
Please try the sample, hopefully it will help making the above more concrete. HTH
You can also look at the Azure AD B2B and B2C (in preview) options - https://blogs.technet.microsoft.com/ad/2015/09/16/azure-ad-b2c-and-b2b-are-now-in-public-preview/