Appian Service Account Users are defined and used inside Appian to identify e.g. process models started by calls from a given API if you are designing web APIs within Appian.
On top of that, there are usually other service accounts in an Appian installation like deployment.daemon (used by deployment processes) and appian.self. I am after the latter one. Is there an official definition for the tasks and purpose of appian.self ?
Related
I'm looking at building a tool that can set the notes for other users on my company's local Skype for business server, providing automated note updates for participating users in my program.
I've found https://msdn.microsoft.com/en-us/skype/ucwa/setmynoteinformation - which provides guidelines on how to set a user's own personal note. Is there an endpoint that an application (with the appropriate permissions) could access to do something similar for other users?
I see the UCWA documentation for https://msdn.microsoft.com/en-us/skype/ucwa/contactnote_ref - but this appears to be a single user centric API for reading a contact's notes. TrustedApplicationAPI looks to mostly relate to meetings - https://ucwa.skype.com/trustedapplicationapi/reference/Resources.html
Is this something that can be done through a REST interface?
Not with UCWA, which isn't designed for doing operations on-behalf-of user; and so will require you to impersonate the user you want to update the note for.
The only option for you will be running a UCMA instance for the purpose (if you're on-premises), and expose that functionality via a custom REST service
I have followed the tutorial for enforcing policies on API calls
http://wso2.com/library/tutorials/2016/02/tutorial-how-to-enable-role-based-access-control-for-wso2-api-manager-using-xacml/
It wasn't easy but I got something up and running. I can change access to different endpoints of an API depending on the user's role.
I have a question. Here's a fictional setup to complete the tutorial:
API EduCollege, with endpoints /student/info and /staff/info (tutorial)
API Prison, with endpoints /prisoner/info and /staff/info (note that it's the same endpoint)
I write a policy EDUCollegePolicy that enables only those with role college_admin to access /staff/info (tutorial).
But there seems to be no way to restrict these college admins from accessing staff info of the prison!
The field resource only contains info about the endpoint.
Is there any way, using this setup, to limit by API?
Or does it maybe require a different JAR add-in, that would send a resource value set to API/version/endpoint instead of just /endpoint?
Oh, by the way: I couldn't set policies according to the endpoints provided in the tutorial. It doesn't seem that it's /staff/info, but I got it to work with regexp .*staff.*info.*. Not nice. I wonder what the actual resource sent from JAR to PDP is, I couldn't find it in any logs, including IDS logs (the IDS acts as PDP)
I've seen various attempts to place two or more web sites (URLs) on an Azure Cloud Service Web Role. The solution is basically to hack up the ServiceDefinitions.csdef file which is a bit of overkill and doesn't appear to be supported by Visual Studio (VS forces you to have a dummy 'master' role and your web sites are manually patched into the configuration file. This is a big red flag that the architecture of multiple websites in a single role isn't anticipated by Azure.)
Instead of hacking the config file, is it possible to create multiple endpoints and associate them with interfaces, such as with WCF? As I mentioned in my original question, I have three ways I want the users to connect into an Azure 'Role': one for the data model (CRUD operations), one for the operator console (start, stop, statistics, etc.), one for the user-defined functions (the web site should be extensible). I would like a separate endpoint for each of these major function groups (that is, well defined interfaces). It's trivial to do in WCF but I don't see how it's done in Azure.
Web Roles support up to 25 input endpoints per deployment, allowing you to host multiple services in the same role (independent of instance count), just by setting up your service to listen on a specific named endpoint which you create ahead of time (it's part of the service definition).
As you scale out to multiple instances, the input endpoints will likewise be load-balanced across your role instances.
I would like to know if the following scenario is possible:
A Fiware Orion Context Broker instance, to which different data providers connect to publish their data. For each data item (context), the particular data provider should be able to control which application or data consumer is allowed to subscribe to this context. Is this possible with Orion? How can this be done?
I've looked into the multitenant model, but I guess that is not the proper way to do this. Am I right? Are there any alternatives? You can protect the Orion instance with a PEP proxy, but I guess it does not allow access control on a per subscription basis.
Any hints would be highly appreciated.
The scenario that you propose can be implemented, if I understood correctly, with Steelskin PEP Proxy and the multitenant mechanism (but with some concerns).
In your scenario, your whole application would be a service (indicated in all transactions with the fiware-service), and each data-provider would own a dedicated subservice (indicated with the fiwareservicepath header). All the users (both administrator from the data-providers and final user and applications) would be users of that service. Using XACML, different permissions can be assigned to each possible action and user in different roles. E.g.: you can create a dataProvider role with full permissions under its subservice and a dataConsumer role that should be able just to subscribe and read.
This scenario has some problems, mainly concerning who creates the users and roles and assign roles to users. In order to use Steelskin, you have to map services to Keystone Domains and subservices to Keystone Projects; and users belong to the domain. It's the domain (service) administrator the one in charge of creating the users, so, in your case, data providers would not be able to create new users (and probably, even assigning them as subservice customers).
If you need an example on how to connect these pieces together to achieve this, take a look at:
https://github.com/telefonicaid/fiware-pep-steelskin/blob/master/keystoneInstallation.md
Hope it helps
I work for a department of a university that uses CAS to provide single-sign-on authentication, and am writing a CakePHP application that needs to use this CAS service. I need to write code that:
Checks with the CAS server to see if the user is logged in
Pulls some credentials from the server if so
Checks the credentials against an internal ACL, as the set of people who can access the application is a subset of the set that can log into the CAS service.
Provides some mechanism for admin users, either by creating special admin users outside the CAS system (with all the headaches that would entail) or by promoting certain CAS users (with the different headaches that would entail).
As a relative newcomer to CakePHP, I frequently struggle with where to stick code that "doesn't belong". The best I can figure is that this code ought to go in the beforeFilter method of the App Controller, but I wonder, is this the best place for it? Also, is it too low in the stack to take advantage of admin routing?
Lastly, I know that CakePHP provides both Auth and ACL components, but when I looked into using them they did not appear amenable to interfacing with outside authentication services. Am I wrong, and would either of these be a good fit for what I need to do?
Thanks!
If you take a look at the Cake's core components you can see that your CAS requirement fits with the type of things components are typically used for (ie. auth/session).
I would recommend creating a CasAuthComponent. There is some information on extending AuthComponent, in a previous answer of mine, which may prove useful if you wish to build on top of the existing core AuthComponent.
A component (essentially reusable controller code) can interact with models, use other components (such as Session) and control user flow (redirects for example)
Note that, the core AuthComponent actually retrieves information from a model (the User model by default), so you could do something similar.
The CasAuthComponent you create could $use an external user model (CasUser maybe) which is responsible for CRUD operations on the data (retrieving users mainly).
You could take this one step further and abstract CAS interactions into a datasource used by this model, but it isn't strictly neccessary if you don't plan on reusing the code in other models.
The end result could be packaged into a plugin:
CasAuthComponent (app/plugins/cas/controllers/components/cas_auth.php)
CasUser (app/plugins/cas/models/cas_user.php)
CasSource (app/plugins/cas/models/datasources/cas_source.php) [optional]
And used in your application by putting the following in your app_controller:
public $components = array('Cas.CasAuthComponent');
If you wish to be able to administer the users from Cake, you can also include a controller and views in your plugin, which allow the user to interact with the CasUser model (ie. $this->CasUser->save()).