I would like to implement access control to a Web service (operations, messages, etc.). My findings indicate that this can be done via WS-Policy or XACML. It looked to me like Axis2 has a good implementation of WS-Policy and one can define assertions that regulate access to every operation for example.
I have some questions:
1) Assuming I have WS-Policy xml file in place, how do I include it in the WSDL (using APIs to include it in the generated WSDL or manually)
2) Assuming I have an application design where client discover services through a broker residing in a repository, are the policies integrated within the wsdl in this repository and every provider who wants to implement a service follows the wsdl+policies in the borker repo OR every provider gets the wsdl from the repo and augments it with its own policies ?
Which approach is correct and feasible in the context of Axis2
3) Can i limit what services a client can search for in the repo by using WS-Policy with UDDI ? Is is supported by Axis2 ?
Thank you very much !!
WS-Policy is a very generic policy language that is not particularly aimed at authorization or access control.
WS-Policy focuses more on what should happen to the message (e.g. signature, encryption...). WS-Policy policies can be referenced to from the WSDL or you can use XSLT to embed the policy inside the WSDL after you generated your WSDL from the service stub.
XACML is much more specific to access control. In that sense, it is probably better suited to your use case. There are several open-source and vendor alternatives. Axiomatics, the vendor I work for, has a JAX-WS interceptor which intercepts your web service message and applies fine-grained authorization using XACML.
Regarding your third question:
Can i limit what services a client can search for in the repo by using
WS-Policy with UDDI ? Is is supported by Axis2 ?
I don't believe you can do that. Also, UDDI isn't actively developed anymore. The standard is a bit old.
Bottom line: WS-Policy is more about how to expose your service and how to handle operations and messages. XACML is more about the actual business authorization logic.
Related
I'm new to SFDC. I need to perform integration between SFDC and EBS. I have a SOAP webservice from EBS to create party,account, account site and site details.
Now i need to call this webservice in SFDC(using APEX). Can you please let me know how i can achieve this (Expecting Step by step explanation) or any document which will tell me how this can be achieved.
Salesforce provides an integrated tool called Wsdl2Apex. It can be used to create Apex classes from the WSDL to call the web service from Apex. See SOAP Services: Defining a Class from a WSDL Document, which includes step by step instructions on how to generate the Apex classes from a WSDL.
Remember that you will also need to setup a Remote Site to allow the callout to the web service URL.
There are a couple of alternatives depending on how complicated your WSDL is.
Firstly, there is also an open source version of Wsdl2Apex.
Secondly, I've created an independent tool that has increased support for various WSDL features. See Dreamforce 2014 Presentation - Improved Apex support for SOAP based web services.
I was wondering what could be a standard way to do access control for some private online services which are hosted on the cloud?
Basically, the service on the cloud is a MapProxy, which itself does not support much authentication methods. Therefore, I was thinking to build a proxy in front of that Map Proxy to do some connection handling. We have decided to use cookies as a way of authentication, and now what is a standard way to do authorization?
Is there any well-documented library could help to build a connection handler for authorization ?
It all depends on what you mean with authorization. If your goal is to define true access control logic e.g.:
a user can call this method of my API if the user role is manager and the user location is the same as the location of the document requested in the API,
then you can use XACML, the eXtensible Access Control Markup Language. I have already replied to a similar question here: RESTFul API endpoint design with filtering and authorization and https://stackoverflow.com/questions/24514711/authorization-framework-in-a-java-web-application/24526891#24526891
To implement ABAC, you will need XACML, the eXtensible Access Control Markup Language. It's an OASIS standard (the same body behind SAML and many other standards). XACML defines:
a policy language to express the authorization requirements above
a request/response scheme to query the authorization e.g. "Can Alice view document d?"
an architecture which defines standard components such as the policy decision point (PDP) and the policy enforcement point (PEP). The latter protects your app and sends the authorization question to the PDP.
When to choose XACML (and ABAC) over other frameworks e.g. Spring Security (and RBAC)? If you have relationships between your users and your data (e.g. ownership, doctor-patient, team leader - team member...), then XACML is for you. If you have many different apps in different languages (Python, Java, .NET, Ruby...) then XACML is for you. XACML is technology-agnostic so it makes it easier to reuse across all your apps.
There are several frameworks that provide you with XACML. Some are vendor-based such as Axiomatics (where I work). Others are open-source such as SunXACML or Heras AF.
HTH,
David.
I am doing a comparison between some Identity Management tools, one of which is the WSO2 Identity Server. I have found a number of wsdl files regarding WSO2 IS web services.
Is there any kind of documentation regarding operations in the wsdl files? Because i can't seam to find any.
Yes. Identity Server contains many web service APIs.. These APIs mainly support for identity and entitlement management functions. You can find web service API such as UserAdmin, RemoteUserStoreManagerService , EntitlementService and so on. But there are some web service APIs for server management functions.. All the UI that you see in WSO2IS server, calls backend web service APIs to get the operation done.. Unfortunately there is no any good document on explaining all these web service APIs. But if you are looking some specific function, You can find them.. As an example, if you want to use WSO2IS as authorization server, You must look about EntitlementService API. More detail on it can be found here. Like that, You can search for some specific topic about WSO2IS in the internet..and get some details about these service.
But, If you like to list and see all WSDL of WSO2IS, You go through this question that is asked in SO. Actually by looking at the WSDL, You can even get some idea about the functions.
There are 2 types of web-services as I know. First one is custom xml formatted messages and the second one SOAP standard xml messages. What are the differences between them? Which one is better, what are pros and cons of each of that two approaches?
By "ordinary" I assume you mean RESTful services. This discussion would be a long one, so I'll try to give you some key points:
RESTful services are the most used flavor of Web Services. They are closely linked to the functionality and principles of HTTP and can be accessed as simple as a GET request (other operations are POST, DELETE and PUT). The core concept is the "resource" which is identified by an URI. Common formats for REST are XML and JSON. It's a pretty straightforward and easy to use technology, which is what makes it so widely available.
SOAP web services are based on XML, most of them adhering to the RPC-style of app design (calling remote methods on a server and getting a response), and use 3 main pillars:
WSDL - Web Service Description Language - used to describe a service in terms of available operations, parameters, etc.
SOAP - Simple Object Access Protocol - used to construct interaction messages between the entities involved (client, server).
UDDI - Universal Description, Discovery and Integration - used to classify and publish available web services to a repository and enable discovery by potential users.
SOAP Web Services tend to have high overhead and generally have very verbose messages, but may be good if you need to implement more complex functionality and interaction in your application.
Strictly speaking only the Soap services are webservices. They are based on the WS-* Specs standardisized by W3C and Oasis. Sometimes a also reffered as Webservice are so called POX-Endpoint (Plain old XML) or REST Endpoint, which allows you to simply get a raw XML via HTTP GET.
SOAP Services carry their schema in form of a wsdl endpoint (usualy append ?wsdl to the service endpoint), so there a lots of tools to create proxy objects and hide the complexity of the webservice call. With POX Services you need to know which schema to use from e.g. the documentation.
SOAP Services carry the payload inside the SOAP Envelope (an XML Schema with header and body with the payload in the body). Having a header independent from the payload allows to reroute the content, sign and encrypt, authenticate etc. without knowing the content. But you pay by additional overhead in the message itself.
POX on the other hand leaves all that to the webserver and relies usualy on HTTP for authentification and compression. Encription and signing had to be done by your system. It is low overhead but also low discoverability.
Whats works best for you depends a lot on your scenario. If you work in a .Net or Java World, you often find it simplest to create a proxy and use that to work with the webservices as remote objects. You get a well build infrastructure and a comfortable programming experience. If youre environment does not support the proxy generation or if it had to be called from anything, POX might the very much more lightweight way to go.
"Web Service" refers to a more abstract and general concept. We can say that anything that can be served on web is a Web Service. SOAP Web Services or RESTful services are special kind of Web Services which has wide acceptance and has their own standards. While SOAP services are built on a new XML based standard, RESTful approach makes use of existing HTTP methods, hence more widely accepted (to my experience).
i am new to REST Service development. I compared the development mechanism for both REST and WS web services and i found that you can create a WS web service using WSDL file that is the top down appraoch (Correct me if i am wrong) and using bottom up approach also, that is generating the classes manually.
But when it comes to REST web service development you have to follow bottom up approach only that is generating the classes manually. NetBeans IDE provides certain wizards for creating REST web service quickly from databases, entity classes and patterns.
I had also seen when you are developing web service in eclipse and you are using wizard in eclipse IDE, you can create a REST web service from WSDL file. I found this very strange. My question here is what are the approaches we can have for creating REST web services. Can we create REST web services using top-down and bottom up approached. If yes then please provide me details.
Thanks.
It is possible to describe a REST service using a contract. This is the intent of WADL and WSDL 2.0. WADL is specifically a REST contract, whereas WSDL 2.0 evolved from the original WSDL spec. to support all HTTP bindings. Since REST services rely on the use of HTTP methods and headers to exchange messages a WSDL 2.0 contract can work. There is a really good explanation here: http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and-wadl
For development of REST services, I'm not sure if NetBeans, Eclipse or other tools specifically support automated REST service from WSDL generation. I would imagine that most are still intended for SOAP service creation. At this point I think WSDL 2.0 and WADL can be used to describe a REST service, but are not intended for automated generation of a REST service.
REST services are simple HTTP request/response,and therefore don't require complex stubs. In most cases it would probably take more time to write the WSDL describing the REST service, than it would take to write the REST service itself.