How to define a XACML Policy inside a XACML PolicySet - access-control

In the past week I have been trying to define a policy inside a policyset of wso2IdendityServer 4.5.0 version.
I am able to create policyset using policyset editor of wso2IdentidyServer 4.5.0 also able add policy in that but the problem is in XML format.
My generated policyset look like this (sample policyset)
<PolicySet>
<Target>
...
</Target>
<PolicyIdReference>simple1</PolicyIdReference>
</PolicySet>
Issues
If we see in <PolicyIdReference> tag, it's taking reference of policy "simple1". But, My requirement is instead of taking only reference name "simple1", it should substitute the complete policy here As I have seen in some of the example . Something like this:
<PolicySet>
<Target>
</Target>
<PolicyIdReference>urn:oasis:names:tc:xacml:2.0:example:policyid:3</PolicyIdReference>
<Policy PolicyId="urn:oasis:names:tc:xacml:2.0:example:policyid:2" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
<Description>
Policy for any medical record in the
http://www.med.example.com/schemas/record.xsd namespace
</Description>
<Target/>
<Rule RuleId="urn:oasis:names:tc:xacml:2.0:example:ruleid:1" Effect="Permit"/>
<Rule RuleId="urn:oasis:names:tc:xacml:2.0:example:ruleid:2" Effect="Permit"/>
<Rule RuleId="urn:oasis:names:tc:xacml:2.0:example:ruleid:4" Effect="Deny"/>
</Policy>
</PolicySet>
As here we can see after tag,its adding policy in policyset.
So My question is which version of wso2 IdentityServer create such types of policyset also what version of xacml schema version it uses?
Thanks and Regards
Deepali Singh

WSO2 Identity Server policy set editor only allows for you to define policy set as policy id references. Therefore selected policy would be added as references. If you need to add completed policy inside the policy set, you can do it using XML view editor. Basically you can edit the created policy set using XML view and add your policy in to it. This would not effect to PDP run time. Both options would work. It is just a limitation in creating policy set from editor UI. However i guess this would be improved to add completed policies from policy set editor UI in future.

You can use the ALFA plugin for Eclipse as well as the Axiomatics Policy Administration Point to author fully-conformant XACML 3.0 policies and policies including the option to either reference policies / policy sets or embed them directly as you requested.
That said, it's probably a better practice to reference policies when it makes sense since it then makes policy lifecycle much simpler.

Related

Can we use AWS Lambdas to check if any mandatory policy is not missing for all newly created roles

how can we make sure that a particular policy ( say S3 bucket access restriction policy ) is attached to all newly created Roles.
Can we write a Lambda that gets triggered only when a new Role is created and check and if missing attached required policies?
AttachRolePolicy API can be used to attach policy to a role. Are there any examples available in AWS Lambda to get this done?
Does Terraform provides any such modules readily available that can be referred in this context.
Yes, this is possible. You can configure a lambda function that's triggered by EventBridge via CloudTrail when a specific AWS API is called. Take a look at the doc here. Since this is pretty simple, I don't think there is a specific module created for this. You can write your own directly based on the resources in the AWS provider.
Python SDK for AWS Boto3, is having multiple APIs that can be used like adding a role, policy etc. It is very simple and documentation is awesome.
https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html
an example to attach a policy to an existing role:
client= boto3.resource('iam')
response = client.attach_role_policy(
PolicyArn='arn:aws:iam::aws:policy/ReadOnlyAccess',
RoleName='ReadOnlyRole',
)
Similarly other clients can be grabbed for other AWS services.

How to install xacml and XACML mediation in wso2am-2.5.0

How to install XACML and XACML mediation in wso2am-2.5.0
I am following this link
XACML is displaying with three times with different version but XACML Mediator is not displaying.
This looks like a problem with the repo URL added in feature installation. Using this URL 'http://product-dist.wso2.com/p2/carbon/releases/wilkes/' instead of 'http://product-dist.wso2.com/p2/carbon/releases/turing/' might help.

Azure API Management - Versioning

We are currently having all our APIs in Azure API Management Portal. The versioning in the API code is handled using the version header. These APIs were deployed into our Production environment mid of Last year. I guess we did not have the versioning concept in the Old API Management Portal and the vendors who are using the APIs which are in Production works without passing the version header (if the version header is not passed, it will fallback to the initial version).
We could see that, currently API Management does have ability to create versions. But, if I create a new version for the existing API – I could see that the existing version (which currently works with or without version header) stops working. It is giving resource not found error. If we go into the API settings page for the Existing version, we could see that the Version Header field is mandatory and not filled.
Is there any way we can default the version header to the initial version through API Management?
This is old but probably worth answering for someone asking in the future.
You can set a header on all API operations in the Azure portal.
Select the API version and then ensure All operations is selected in the list of operations.
Then in the Inbound Processing section click + Add policy.
Set headers is one of the options.
Select that and add the details for the header.
Save and repeat for the other versions you have defined, obviously setting the correct version each time.
Hope this helps.
You may also define passing the version as a header parameter when initially adding the API to API Management as Open API Specification Full definition and then set the Header definition in Versioning scheme.

WSO2 API Manager - "Make this the default version" causes authentication errors?

I have an API that works no problem providing the "Make this the default version" checkbox isnt checked, once checked I get this error back
<ams:fault
xmlns:ams="http://wso2.org/apimanager/security">
<ams:code>900906</ams:code>
<ams:message>No matching resource found in the API for the given request</ams:message>
<ams:description>Access failure for API: xxxx/xxxx, version: v0.1 with key: xxxxxx</ams:description>
</ams:fault>
Is there something I have missed at all?
Thanks,
Ash.
EDIT - Extra Detail and Logs
TID[-1234] [AM] [2014-07-10 13:05:56,238] ERROR
{org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler}
- API authentication failure org.wso2.carbon.apimgt.gateway.handlers.security.oauth.OAuthAuthenticator.authenticate(OAuthAuthenticator.java:157)
org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler.handleRequest(APIAuthenticationHandler.java:92)
org.apache.synapse.rest.API.process(API.java:285)
org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:83)
org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:64)
org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220)
org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:83)
org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
org.apache.synapse.transport.passthru.ServerWorker.processNonEntityEnclosingRESTHandler(ServerWorker.java:344)
org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:168)
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:744)
Please save and publish the API once you made the change to the API. This may be causing the issue.
Once you have published you should see 2 sets of production url (one with the version and one without the version). Please check if the same is available in the API store for your API.
You'll first want to turn on wire logs in that environment by editing your ../repository/conf/log4j.properties file and restarting the service. This will allow you to see the request headers for both the initial request to the gateway and the request from the gateway to itself (or other gateways in your cluster) since that's how requests to a default API version are resolved. This can help you identify whether your Authorization header values are actually making it to the authentication handler.
After you take a look at this, note that when you publish an API with a default version, you're actually creating (or updating) two separate synapse configurations for the API: a versioned configuration and an unversioned configuration. The portion of the latter's definition that you need to check is:
<else>
<header name="WSO2_AM_API_DEFAULT_VERSION" scope="transport" value="true"/>
<property name="uri.var.portnum" expression="get-property('https.nio.port')"/>
<send>
<endpoint>
<http uri-template="https://localhost:{uri.var.portnum}/myApi/v1">
<timeout>
<duration>60000</duration>
<responseAction>fault</responseAction>
</timeout>
</http>
</endpoint>
</send>
</else>
By default, the newly generated definition for the default version attempts to send the request to localhost, which may not be what you want. Check at ../repository/deployment/synapse-configs/default/api and make sure that this definition is correct.
Since it looks like this is actually an authentication error, you should also test a new subscription. Create a new application with some subscriber, subscribe to the API, and generate new access tokens. I wouldn't understand why (since setting a default version doesn't create a new API entry in the AM_API table) but this could possibly be due to the access token credentials being invalid for the default version, and generating new tokens should (in theory) test against this.

Apache axis2 and Rampart not preventing 'replay attacks'

We use one of the older versions of apache axis2 for our web services framework. We are using rampart 1.2 as part of that.
Am trying to use password digest with ‘nonce’ and ‘timestamp’ mechanism for authentication. We’re getting rampart to do the verification.
I’ve got the authentication verification mechanism working fine (inc. password callbacks, etc.)
The issue I’m having concerns getting rampart to recognise a ‘replay attack’, basically the functionality of the rampart module associated with recognising these seems to be inactive.
I can send the same security header to my axis2 service any number of times (even sending a security header I generated yesterday) and it authenticates fine and completes the webservice request.
My best guess is : I’m missing a config setting somewhere for the rampart module that enables the functionality to detect replay attacks.
I’ve tried both the config suggestions given in the links below (in the services.xml file) and neither seem to work :-
http://hasini-gunasinghe.blogspot.com.au/2012_02_01_archive.html
http://axis.apache.org/axis2/c/rampart/docs/configurations.html (right at the bottom, it mentions ‘Replay attacks’)
Anyone able to help or give me some idea what I'm missing and where (I'd imagine it's config setting related) ?
I've got the module declaration for rampart in my axis2.xml file :-
<module ref="rampart"/>
And I have what I believe to be the rampart config settings in my services.xml file after all my operations are declared ;-
<parameter name="InflowSecurity">
<action>
<items>UsernameToken Timestamp</items>
<passwordCallbackClass>com.myCompany.service.dummy.MyAuthenticator</passwordCallbackClass>
</action>
</parameter>
<rampart:rampartconfig xmlns:rampart="http://ws.apache.org/rampart/policy">
<rampart:timestampprecisioninmilliseconds>true
</rampart:timestampprecisioninmilliseconds>
<rampart:timestampttl>300</rampart:timestampttl>
<rampart:timestampmaxskew>300</rampart:timestampmaxskew>
<rampart:timestampstrict>false</rampart:timestampstrict>
<rampart:ReplayDetection>1000</rampart:ReplayDetection>
</rampart:rampartconfig>
If you are using rampart-1.2 you will have to implement the replay detection in your service.
The incoming TimeStamp information is available in the Security header processing results included in the message context properties under the key "org.apache.ws.security.handler.WSHandlerConstants.RECV_RESULTS". This is a Vector, and the first item of this is a "org.apache.ws.security.handler.WSHandlerResult" instance (wsResult in the next code snippet).
Then you can obtain the timestamp information as shown below:
actionResult = WSSecurityUtil.fetchActionResult(wsResult,
WSConstants.TS);
if (actionResult != null) {
Timestamp timestamp = actionResult.getTimestamp();
//Your validation goes here...
}
As suggested by the blog post you referenced you can try upgrading to rampart-1.6.2 and using the policy based configuration.