Restrict Access to External Facing Portal

[Former Member]

Hi Portal Community I need your collective help!

I have the following scenario:

• Single SAP NW Portal (7.31)
• Two sets of users "Internal" and "External"
• SAP Web Dispatcher as a reverse proxy/application gateway in a DMZ
• Two URLs http://portal.internal.com/irj/portal (internal) and http://portal.external.com/irj/portal (external) resolving to the same portal system

To start with internal users should only be allowed to access the portal when they are on the corporate network - they should not be allowed to log on via the external URL (e.g. when they go home or are out of the office).

At some point in the future internal users will be given limited access to certain content via the external URL (but not all the content they have when accessing via the internal URL). For example they may be able to see corporate news and check their payment summary externally but they won't be allowed access to change their bank details.

I spent some time thinking about this and did some searching for similar scenarios:

from

from

from

I have come to the conclusion that in order to block access for internal users on the external URL I would need to write a custom login module (JAAS module) that would check the URL (or URL alias) and if using the external URL it would check that the user was assigned to a certain UME group (e.g. External Users Group). If the user wasn't in the group it would fail the log on attempt. The other option is a separate portal (but I would like to avoid that if possible).

Once internal users are given access via the external URL I thought about using the Filter ID feature of the portal to filter out any top level entry points that should not be shown to the user. The problem with this is that it only filters the entry point, it doesn't actually block access. If the user has for example saved a portal favourite to a filtered area they can still use that favourite to access it.

So I throw it open to you guys and gals... please make suggestions and help me brainstorm this

Thanks in advance,

Simon

[abdulbasit · Accepted solution]

Hi Simon,

You can also consider creating a virtual host for your external domain and restrict access to the applications in "Application Aliases" tab. However, this will only allow you to restrict access by application. I would combine this solution with custom login module which controls the access by user groups (or any other criteria).

Filter could also be useful but unfortunately it is only possible to create rules by url aliases. It would be great if we could also create rules according to the whole domain.

Cheers,

Abdul.

[Former Member · Accepted solution]

Thanks Abdul,

I have never played with using Virtual Hosts before I assume this is what you are referring to:

http://help.sap.com/saphelp_nw73/helpdata/en/4a/8f9f1263dd3894e10000000a42189c/content.htm

I have to admit I am not sure how this helps me - can I ask you to explain in more detail? Since I am already using a Web Dispatcher I can create a different host name (e.g. an externally resolvable host name), I just don't see the advantage of the virtual host...

Thanks for your help,
Simon

[abdulbasit · Accepted solution]

Hi Simon,

Sorry for replying late. I was on vacation last week and my notebook crashed. I'm still trying to move to a new notebook.

Regarding to your question, yes I'm referring to the Virtual Host configuration that explained in your link. It is almost similar to the Virtual Host configuration that you can perform in Web Dispatcher or Apache Reverse Proxy. Additionally, it gives you the capability of restricting access to the applications as shown in the picture:

In your case if you use URL Aliases and filters to distinguish between internal and external desktop, users can still access internal content from external url by providing the direct url. However, if you restrict access to the internal application in external virtual host configurartion, they will not be able to use these applications even they provide direct link. Then, you will not need to add/remove roles dynamically to the users.

Hope it helps..

Cheers.

[Former Member · Accepted solution]

That won't work if the same application is used in both scenarios, eg. /irj is the first one that comes to my mind. I think the obvious solution here would be for SAP to implement a scenario approach (or scope?) which could be used for scenario specific assignment of authorizations. In other words assign portal role X to user Y only for scenario Z and scenario Z could be restricted further for example for virtual host A, portal alias B, etc.

[Former Member · Accepted solution]

Thanks Abdul,

I see what you mean - but won't users still get the portal role and just get error messages when they try to access the application? Or are you saying use a combination of Entry point filtering and restricting access via the virtual host?

I think for the portal I would need to allow the /irj application access and I would probably have to do a lot of trial and error to work out which others.

Thanks for getting back to me.

Simon

[abdulbasit · Accepted solution]

Hi Simon,

You are right, you need to combine "Entry Point Filtering" and "Virtual Host" solution. Virtual Host solution can only help you to make sure that external users are not accessing to the specific applications by using direct url.

In the "Application Aliases" tab, all applications are selected by default. Instead of selecting only specific applications (including /irj), it might be easier to select all and deselect only specific applications that you want to prevent. It depends on your requirement. You need to know the applications that you want to restrict.

It might not be the best solution but I prefer this method over changing user roles dynamically.

Cheers,

Abdul.

[former_member182254]

Hi Simon,

If after 2 years your question is still valid then you might find the answer of it in the following blog: .

Thanks to for pointing to your question.

Regards,

Dimitar

[Former Member]

Hi Simon,

I know you posted this long back... but did you finalize on your approach?

We have exactly the same requirement for exposing the portal over internet but the customer doesn't want to expose KM.

Mahesh

[Former Member]

Hi Simon,

                Though  I am kind of late into the discussion,but seen it earlier , as I was busy to some occasion I could not reply. To me for external access you can custom design a framework page. Since you are using reverse proxy you can get your external path redirected to the internal link like below:

/irj/portal(external)-->/irj/custom(internal,using proxy pass)

now here,as per my view, you will create a rule that will launch the custom framework page(desktop), designed for external access, here you can filter out the roles that are not necessary. I mean in the client side by using LSAPI or EPCF(I worked on nw 7.3 portal, with full customization). A bit of jQuery might help. As Noel rightly said , which was my view also, to keep different roles so that you can filter them easily.

Regards,

Asad

[nol_hendrikx]

Hi Asad,

Removing the portal nodes with LSAPI might be a solution, but it is still not safe. Users can copy and paste the internal URL and change it into an external link and access the application. Removing the portal role instead is safe, but that will give a lot of write actions on the UME, unless there is an in-memory variant for this.

There must be some dynamic role assignment to accomplish this, I guess.

Cheers,

Noel

[Former Member]

Firstly thanks for everyone's input on this.

I would like to take a step back here and imagine the feature I would really like (in an ideal world) in case any of the product managers are listening (hint: )

So at a high level if would be:

The ability for portal roles (and other PCD content) to be filtered based on the access channel.

So based on how the user has got to the portal (internally or externally) the portal would allow me to tag a PCD role as available or not. This is very similar to the Filter ID currently available but needs to add a security aspect not just filtering.

Then I could have 2 roles both assigned to the user (1 Internal ESS role and 1 external ESS role) and depending on how the user got in they would only get one or the other.

For now I am probably going to recommend two portals, in this case we probably don't have the appetite for a custom login module..

Cheers,

Simon

[hofmann]

HI Simon,

The ability for portal roles (and other PCD content) to be filtered based on the access channel.

I am just not sure if this is something (easily) doable with the on premise portal. Separating access is more than just showing content, security is important and needs to taken into consideration. I am also not sure no matter how much SAP PM is listening, if this is something we will see ... ever. Actually, IMHO this is where SAP can place Cloud Portal. Although it depends on the cloud <-> on premise integration.

As stated before, you are not the first to be confronted with this problem and I am sure SAP was noticed about this scenario way before our time (well, sort of).

Maybe someone from SAP ( etc) can share their view: on premise of cloud, and implementation implications (you will still end up with 2 users).

[AviadRivlin]

I would like to start and state: Yes we are! (listening...)

Looping in to comment about this potential portal enhancement.

Aviad

[Former Member]

It might be something you have already ruled out but would it be possible to have different user IDs for internal and external usage? Obviously also in that case there are things to consider for example how to prohibit the users from using their internal credentials when accesing the portal externally but maybe you will figure out a way that will work for you.

[hofmann]

Giving users 2 IDs normally does not work. It's confusing for everyone. If you want to use something like that, you'll have to use also a IDM solution that maps 1 userid to another userid depending from where you logged on.

For the user it will be 1 userid only, but for the portal 2 different users (license!) and you'll still have to hide this little fact from the user when working within the portal.

[nol_hendrikx]

Hi Simon,

Nice problem do you have!

If I understood you right, your internal users nowadays login via the intranet and have full access to their functionality.

In the future they can login via the internet as well, but with less functionality, right?

As an example:

ROLE_INTERNAL_MAX_FUNCTIONALITY (INTRANET)

Address

Salary

Personal data

Leave request

ROLE_INTERNAL_LESS_FUNCTIONALITY (INTERNET)

Address

Personal data

Phew... that's not easy

The problem is not authenticating but role providing in my opinion. You can filter out if the internal user is logging in via intranet or internet. You can block users from the intranet to access the portal via the internet (same network).

If they login via the business network to http://portal.external.com/irj/portal they will be forwarded to http://portal.internal.com/irj/portal.

They will get the ROLE_INTERNAL_MAX_FUNCTIONALITY.

If they login from home (internet access) to your http://portal.external.com/irj/portal link, they will get the ROLE_INTERNAL_LESS_FUNCTIONALITY.

Removing rights is difficult. What you might try is give the internal user the ROLE_INTERNAL_LESS functionality and when they login from the business network give another role to that user that merges pages and adds additional functionality.

The question is how to dynamically add another role to the user, but I think that might be trying worth!

Cheers,

Noel

[Former Member]

Maybe you could configure SAML for both scenarios. Depending which authentication (internal or external) is used, you could setup UME attributes based on SAML assertions which you can then use to grant access to specific portal content.

[Former Member]

Hi Samuli,

I'm not sure I understand what you mean... can you elaborate a bit?

Thanks

Simon

[Former Member]

Simon Kemp wrote:
I'm not sure I understand what you mean... can you elaborate a bit?

Which part do you want elaboration on? The bit of having different SAML configurations for the two URLs, the bit of assigning custom UME attributes based on SAML assertions or the bit of how to assign portal content based on custom UME attributes? I don't remember seeing a document discussing all 3 but I remember seeing separate documents for each.

[Former Member]

Hi Samuli,

Probably the last two really... in bold below, (or maybe all three 😞

Which part do you want elaboration on? The bit of having different SAML configurations for the two URLs, the bit of assigning custom UME attributes based on SAML assertions or the bit of how to assign portal content based on custom UME attributes? I don't remember seeing a document discussing all 3 but I remember seeing separate documents for each.

Thanks for your help,
Simon

[hofmann]

Hi Simon,

all depends on how you define "give access to portal content". If you do not assign goups (and therefore roles) to a user based on logon information, you only assign navigation points, but you do not restrict access.

In you case, you should use separate portals for internal and external access. That is - of course - the best way to treat internal and external users. An external user will never be able to accidentally get access to internal information / application when the application is not accessible. True story.

If you want to get administration and maintenance effort low, assign the user to a group at logon. But your code needs to handle the rare cases too (external user visiting internal facility, so simple IP lookup does not work, closes browser, will the user stay attributed to group?)

As this is actually a not so rare requirement, share your final findings with the portal team () as this is interesting for SRM scenarios too.

[Former Member]

Thanks Tobias,

Yes of course it would seem that a separate portal is the easiest and best way to do this.

After that as also suggests it would seem like a custom login module would be the way to do it. The custom login module can work out if the request is coming in from internally or externally and then dynamically assign groups/roles to the user. For example I could have an internal ESS role and an external ESS role, if the user was in an ESS group they could be assigned the internal or external role depending on how they access the portal.

I will of course update this discussion if/when a final method is chosen.

Cheers,
Simon

[Former Member]

Hi Simon

I've seen weave some magic with a custom login module and a dynamic resolution service. Hopefully he can help you here...

Regards

Glen

[Former Member]

Hi Simon

I've been thinking about this a little more...

Have you considered creating separate roles for internal and external access and assign each to a group? You could then create a login module that dynamically assigns one of the groups, depending on which hostname is used to access the portal. Here's a that describes the dynamic assignment of groups (amongst other things)

Regards

Glen