I've got a client that would like to use Magento's web services API to create and update customers. Using the API we can easily manipulate the system defined attributes - firstname, lastname, etc using the V1 or V2 API. Se we're good to go there.
This is where it gets sticky - this site uses Magento Enterprise 1.12 and we have added some custom customer attributes for linking the Magento customers to their CRM data on an external system. Using the V1 API, I have full access to the custom attributes. However, the V2 API will not expose them. Since the caller is coming from .NET, I believe he needs to use the V2 API.
Tracing the code with a debugger, I see that the V2 code gets all the attribute data and then drops all the custom data when the web service response is generated. I tried adding the attributes to the Customer (Mage/Customer/etc/) WSDL and WSI files, but that did not do the trick.
Can anyone give me a pointer as to what I should do to expose the customer attributes?
Greg
Create a new module
In Your_Module/etc/wsdl.xml and wsi.xml add your new attribute in the same node as in the Mage_Customer wsdl.xml and wsi.xml
Magento merges all wsdl.xml and wsi.xml files together
Here's an example of a wsdl.xml file that I used to add customer_number to the API.
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns:typens="urn:{{var wsdl.name}}" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/"
name="{{var wsdl.name}}" targetNamespace="urn:{{var wsdl.name}}">
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:Magento">
<complexType name="customerCustomerEntity">
<all>
<element name="customer_number" type="xsd:string" minOccurs="0" />
</all>
</complexType>
</schema>
</types>
</definitions>
Related
I have one API replicated in multiple backends. I don't have any condition that can differentiate between backends. I tried to use dynamic endpoints and change the message mediation flow:
https://apim.docs.wso2.com/en/latest/deploy-and-publish/deploy-on-gateway/api-gateway/message-mediation/changing-the-default-mediation-flow-of-api-requests/
However, the only difference between requests is the IP address of the backend server:
https://{uri.var.host}/resource
I'm thinking to create every time the API and change the endpoint address but this solution can be complex as I will have the same API replicated many times (around 100) in the wso2 api manager. There is any other solution that can fit my use case?
We can make use of Dynamic Endpoints to achieve your requirement. But, it is required that the client applications need to either send a param or a Header to filter and construct the BE server URL in the mediation sequence to route the requests in the API Manager.
If the client applications can send a header specifying a unique (server) name or any other value while invoking the API, we can use the key to filter (or perform a switch case operation) and construct the BE server URL in the mediation sequence and route them to the respective BE services. Refer to the following Docs for more information.
A sample mediation sequence will be as follows (the client application will be sending a header named as X-ServerName with a name)
<sequence xmlns="http://ws.apache.org/ns/synapse" name="dynamic-endpoint-seq">
<!-- extract the name from the header -->
<property name="server_name" expression="$trp:X-ServerName" />
<!-- switch case for all applicable names -->
<switch source="$ctx:server_name">
<case regex="server-one">
<property name="service_ep" value="http://server-one-ip/resource"/>
</case>
<case regex="server-two">
<property name="service_ep" value="http://server-two-ip/resource"/>
</case>
<default>
<property name="service_ep" value="http://server-default-ip/resource"/>
</default>
</switch>
<header name="To" expression="get-property('service_ep')"/>
</sequence>
Dynamic Endpoints in API Manager
Switch Mediator in WSO2
I am an Apigee beginner. We are doing a migration to Apigee.
We have our environments in our host names, for example:
something.int.other.thing.co.uk
something.test.other.thing.co.uk
something.stage.other.thing.co.uk
something.prod.other.thing.co.uk
I would like to be able to map them to the 4 environments of the apigee api proxy itself, respectively int, test, stage, prod.
I currently have one Rest resource for them, for example: /resource
Basically I would like the apigee api proxy with one rest resource, to map to 4 different target endpoints, depending on the environment.
So far I have tried to do it from the UI and have not been able to do so.
I have been going through the documentation and I have found these so far:
According to this it should be possible:
"An API proxy can contain zero or more TargetEndpoints." (TargetEndpoint section)
http://apigee.com/docs/api-services/content/api-proxy-configuration-reference
According to these, you can make routerules to the proxy endpoint, but I have not been able to implement it to the targetendpoint:
Create a New Endpoint on an existing API Proxy with "No Target Endpoint"
One API proxy calling two different target endpoints
I also tried doing something along the lines of this, for TargetEndpoint, where I tested for the environment name, but it didn't work:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
<Description/>
<Flows/>
<PreFlow name="PreFlow">
<Request/>
<Response/>
</PreFlow>
<HTTPTargetConnection>
<URL>something.int.other.thing.co.uk</URL>
</HTTPTargetConnection>
<RouteRule name="int">
<Condition>environment.name == "int"</Condition>
<TargetEndpoint>something.int.other.thing.co.uk</TargetEndpoint>
</RouteRule>
<RouteRule name="test">
<Condition>environment.name == "test"</Condition>
<TargetEndpoint>something.test.other.thing.co.uk/</TargetEndpoint>
</RouteRule>
<RouteRule name="stage">
<Condition>environment.name == "stage"</Condition>
<TargetEndpoint>something.stage.other.thing.co.uk/</TargetEndpoint>
</RouteRule>
<RouteRule name="prod">
<Condition>environment.name == "prod"</Condition>
<TargetEndpoint>something.prod.other.thing.co.uk</TargetEndpoint>
</RouteRule>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
</TargetEndpoint>
So is this possible?
Apigee supports the concept of Target Servers -which abstracts the backend host from the proxies and also provides load balancing. Same target servers can be configured to point to different host for each environment (this concept is built in to Apigee already).
Take a look, this should help.
Srikanth
LoadBalancer and TargetServer settings go in the TargetEndpoint definition, specifically in the HTTPTargetConnection element.
Check the example here:
http://apigee.com/docs/api-services/content/load-balancing-across-backend-servers
If you do want to curl a TargetEndpoint definition to your API proxy, have a look at the following sample script to see working API calls:
https://github.com/apigee/api-platform-samples/blob/master/tools/proxy_gen.sh
This script shows you how to create an API proxy and update ProxyEndpoint and TargetEndpoints via API calls.
I'm considering migrating my client application from using a XACML 2.0 authorization service to using a newer XACML 3.0 service.
What changes or issues will I run into in migrating my client app from making XACML 2.0 requests to making XACML 3.0 requests?
The biggest difference between XACML 2.0 and XACML 3.0 for your client app is that the structure of the attributes in the authz request have changed significantly in XACML 3.0.
In XACML 2.0, attributes were organized into subject, resource, environment, or action categories using XML element tags:
<?xml version="1.0" encoding="UTF-8"?>
<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os access_control-xacml-2.0-context-schema-os.xsd">
<Subject>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>Julius Hibbert</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#anyURI">
<AttributeValue>http://medico.com/record/patient/BartSimpson</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>read</AttributeValue>
</Attribute>
</Action>
<Environment/>
</Request>
In XACML 3.0, these categories are indicated using XML attributes instead of XML element tags:
<?xml version="1.0" encoding="utf-8"?>
<Request xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd" ReturnPolicyIdList="false" CombinedDecision="false" xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Julius Hibbert</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">http://medico.com/record/patient/BartSimpson</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment" />
</Request>
The <Subject> element in XACML 2.0 becomes <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"> in XACML 3.0, for example. Ditto for the resource, environment, and action categories.
This structural change simplifies the processing model for handling requests and makes it easy to extend the model with custom application-specific or domain-specific categories without running afoul of schema validation.
There are new data types and functions defined in XACML 3.0 for use in policy definitions. The AnyURI data type is now distinct from the string datatype. Several of the 2.0 combining algorithms have been deprecated in favor of new 3.0 equivalents that define more precisely how indeterminate states propagate up through the policy decision tree. The old combining algorithms are still included as "legacy" artifacts.
XACML 2.0 requests and policies can be mechanically converted to XACML 3.0 format with no loss of information. Converting a 3.0 response back to 2.0 format is doable if you stick to simple permit/deny responses.
Please check the OASIS XACML TC wiki for an official list of differences:
"Differences between XACML 2.0 and XACML 3.0"
In a nutshell...
The key difference between XACML 2.0 and XACML 3.0 is in new features such as
obligation expressions: you can have dynamic parts to your obligation statements
the introduction of advice which effectively is generalizing obligations to a broader scope
the introduction of the XACML v3.0 Administration and Delegation Profile Version 1.0. To date Axiomatics and ViewDS (http://www.viewDs.com) are the only complete XACML 3.0 implementations that includes delegation. It is a key feature for cloud and federated deployments. The delegation model is the result of 5+ years of R&D at the Swedish Institute of Computer Science (SICS).
This information is summarized on the XACML TC wiki page at OASIS. The TC is backed by such leading organization as Oracle, IBM, and Axiomatics. The editor of the XACML 3.0 specification is Axiomatics's CTO, Erik Rissanen.
Also, Kuppinger Cole delivered a webinar on the topic: "Policy Based Access Control with XACML 3.0".
Lastly, I summarized the new features on "Enhancements and new features in #XACML 3.0".
May be another useful web page to understand about XACML3 features:
What is new with XACML 3.0
We have an ADFS 2.0 installation that's working well for our MVC apps in our various environments. I believe it uses "passive authentication" (I'm still getting used to the proper terminology) - it definitely is where it redirects the user to our adfs proxy if the user is not logged in and adfs redirects the user back to our MVC app once they are logged in.
We are now beginning to expose some secured web services and want to tap into this same authentication system. My understanding is that I want to use ws2007FederationHttpBinding as my binding to do this. I believe I have my WCF's web.config all setup for this but my struggle is now centered around the FederationMetadata.xml file.
Looking at this file, I see some things that obviously need to change, such as entityID="http://localhost/UserServices" and the certificate. Then there are some things that I have no clue what they are and if they need to change or not, such as EntityDescriptor ID="_2b510fe8-98b8...... and <ds:SignatureValue>CZe5mEu19/bDNoZrY8f6C559CJ........
Where can I get a better understanding on how I should be managing this file for my various environments? I have the following environments hosting these services that we'll be deploying to one way or another:
Individual developer workstations (3x for now, more later)
A shared Dev environment for people writing apps against these services but not necessarily modifying the services
QA
Staging
Production (3 different environments with different certs/domains/etc.)
As such, we have a fairly streamlined process in place managing our web.config files in the different environments using transforms and finding/replacing certain tokens, so I'd like to do the same thing with this xml file. So ultimately, all I'm looking for is some understanding in what changes are necessary when managing this FederationMetadata.xml file for my various environments.
My current FederationMetadata.base.xml file is below and I BELIEVE this is about right (I just need names/roles) and I just need to intelligently replace the various tokens, such as ~RootServiceUrlTokenToReplace~, in here:
<?xml version="1.0" encoding="utf-8"?>
<EntityDescriptor ID="~EntityDescriptorIdTokenToReplace~" entityID="http://~RootServiceUrlTokenToReplace~" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#~ReferenceURITokenToReplace~">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>~DigestValueTokenToReplace~</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>~SignatureValueTokenToReplace~</ds:SignatureValue>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>~CertificateTokenToReplace~</X509Certificate>
</X509Data>
</KeyInfo>
</ds:Signature>
<RoleDescriptor xsi:type="fed:ApplicationServiceType" protocolSupportEnumeration="http://schemas.xmlsoap.org/ws/2005/02/trust http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706">
<KeyDescriptor use="encryption">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>~CertificateTokenToReplace~</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<fed:ClaimTypesRequested>
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
<auth:ClaimType Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" Optional="true" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
</fed:ClaimTypesRequested>
<fed:TargetScopes>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://~RootServiceUrlTokenToReplace~</Address>
</EndpointReference>
</fed:TargetScopes>
<fed:ApplicationServiceEndpoint>
<EndpointReference xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://~RootServiceUrlTokenToReplace~</Address>
</EndpointReference>
</fed:ApplicationServiceEndpoint>
</RoleDescriptor>
</EntityDescriptor>
A WIF-based application's FederationMetadata.xml is not related to the claims-based web services it offers.
(A URL pointing to) FederationMetadata.xml is used by AD FS, to automatically update the information to be used in a Relying Party Trust. AD FS can for example regularly query this URL, and update the Relying Party Trust information accordingly.
The information about a web service (claims-based or otherwise), i.e., its metadata, is published as a WSDL document. In a WCF-based service this is a URL that often looks like this: http://myhost.example.com/appName/serviceName.svc?wsdl. That WSDL document often does not exist as a physical file, but is automatically generated by WCF.
I have found a partial answer to my question in this blog post. I'm looking into it more to discover whether or not this answers all of my questions. I just found it. Apparently I do need to change my EntityID (that contains the URL) as I redeploy this to different environments but the SignatureValue contains a hash of that URL (among other things?) so by modifying the URL, I invalidate the SignatureValue and it needs to be regenereated. Apparently this FederationMetadata Generator can help me with this.
I am very new to ELK stack and am trying to hit APIGEE analytics REST API, which is in the form of a URL. The response from the URL would be a JSON file. What is the best approach to go ahead with the implementation?
I hope the question is still valid. If I understand it correctly you want to send logging data to an ELK stack. So why not send it instead of retrieving it?
Below is an example of how this policy works on the apigee platform. You need to add it to any API proxy and preferably at the PostClientFlow:
....
</PostFlow>
<PostClientFlow>
<Response>
<Step>
<Name>Message-Logging-Policy1</Name>
</Step>
</Response>
</PostClientFlow>
Below the policy.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging async="false" continueOnError="false" enabled="true" name="Message-Logging-1">
<DisplayName>Message Logging</DisplayName>
<Syslog>
<Message>{system.time.year}-{system.time.month}-{system.time.day}:{system.time.hour}-{system.time.minute}-{system.time.second}.{system.time.millisecond} {apiproxy.name} {request.header.x-requestor-app} {request.header.x-realm} [{request.header.x-requestor-type}|{request.header.x-requestor}] </Message>
<Host>logstash.xxxx.com</Host>
<Port>514</Port>
</Syslog>
Hope this helps.