Dear all, We have the following problem. There is an Appian infrastru

...cess the public URL then they will get access potentially to other existing internal applications externally and we might not want to do that.
Do you have any other ideas on how to block this?
Regards,
Nikos

I know 1 Appian insurance can only have 1 URL so the attached setup is not supported.

Appian has several "layers" of security in which you explicitly deny certain users access to objects. It might be worth testing that?

It's just a case of ensuring nothing slips through the net with group administration.

You could also use the sites functionality but that is limited in use at the moment.

One final thing ... Embedded Sail and web api's etc are a great way of building custom interfaces that may satisfy requirements like this?

We have implemented the following – there is an Appian application server in DMZ and one internal and one external web servers. Appian is configured to use SSO authentication when users come from the internal network. In this case internal users can’t login to applications if they access Appian externally (they have to go via remote desktop). We have also implemented URL filtering so no one, even administrators, can access designer or admin functionality from the external network.

We were actually thinking something like what you describe Alexey. I am pretty sure this is possible I wonder why shyamb says that this is not supported. I am not sure if they would like to switch all internal users to SSO authentication but that is one option. To davidwi, yes we are thinking of using the authorization of Appian to configure application access, record access etc. Now about Embedded Sail, we also looked into that but it appears that you have to do quite a bit of custom development. Essentially you are not embedding sail but you are developing a new client using the .js library provided by Appian. Not only that but the client you developing can never support records or reports. I am not sure I am so keen on embedded sail. The only advantage I can think of is that you are actually delegating authentication in embedded sail to an IdP so you can practically implement any type of authentication you would want. However this is because you are developing a new client.

I said it's not supported as you can only set 1 server and port in custom.properties.

Embeded SAIL, I agree with you. if you already have another web application it makes sense. Else you have to create the web application.

@Alexey, does both your internal and external web servers have same domain and port? If possible can you share value for conf.suite.SERVER_AND_PORT in custom.properties (confuscate or use random, I just want to understand the setup).

yes, they do have the same URL but it resolves to different IP addresses depending on whether you access it internally or externally. conf.suite.SERVER_AND_PORT=<appname>.<domain>.com

Thanks Alexey. That makes perfect sense.

@nikolaosm, you could do the same as Alexey. It needs to be managed at the DNS level to choose which web server to route to based on internal or external network.

I have another question related to this topic. I guess the unattended activities (at least the java smart services) are executed on the application server. Suppose you have configured two application servers. Can you configure somehow which application server executes the unattended activities so that only the internal application server executes such unattended activities?

This is not possible. Each app server's unattended poller will poll the engine's work queue and pick up items as they become available, so there is no guarantee which app server will do which work (user's session does not matter for unattended activities). That said the data will be stored temporarily only in the app server's heap until it is discarded, garbage collected or the app server restarted.