Authentication by UserId and Password is the part of discussion here. In the business process we frequently have requirements to authenticate users based on some condition like 'who they are' and 'where they are from'. Restricting access based on some criteria other than the identity of the user is generally called as Access Control. Let's discuss how Access Control can be achieved.
Think of a situation as represented in the diagram, where the XYZ company Inc., has a user to access the integration server. He may deliver any message there as the sender agreement does not prevent it. How can we enforce security?
Solution
The client sends a message to integration server using his service as sender service and his user configuration. Configurator assigns user to business system services or business services which have been agreed with his client.
The XI runtime inbound processing (adapter engine or integration engine) receiving a message checks if the sender service has a user access list. If it has one, the current user must be one of the user access list, otherwise the message will not be accepted.
If it does not have one, no check will be executed and the message will be accepted.
User Access Lists for Services (SP13)
Client sends a message to IS using his service and user.
In configuration, assign user to service that has been agreed with client (restrict access to sender service to specific users.
During runtime, check if current user is part of user list, otherwise message will be rejected
Interface-Specific User Access Lists (SP15)
Concept enhanced to sender agreements to achieve interface dependency. Assign users to a sender agreement to restrict access to an interface to specific users. Only those users can be assigned that are already assigned to the service. To specify authorized users for a particular interface of the sender, in the editor Edit Sender Agreement, choose the Assigned Users tab page and insert the users line by line. Note that the users specified for the sender agreement must match those assigned for the service, or must at least be a subset of these.
For some adapter types, it is not absolutely necessary to configure a sender agreement unless you want to make additional security settings. If you want to make access to the runtime environment dependent on the sender interface, you must define a separate sender agreement that contains the list of authorized users.
Supported Adapters:-
Think of a situation as represented in the diagram, where the XYZ company Inc., has a user to access the integration server. He may deliver any message there as the sender agreement does not prevent it. How can we enforce security?
Solution
The client sends a message to integration server using his service as sender service and his user configuration. Configurator assigns user to business system services or business services which have been agreed with his client.
The XI runtime inbound processing (adapter engine or integration engine) receiving a message checks if the sender service has a user access list. If it has one, the current user must be one of the user access list, otherwise the message will not be accepted.
If it does not have one, no check will be executed and the message will be accepted.
User Access Lists for Services (SP13)
Client sends a message to IS using his service and user.
In configuration, assign user to service that has been agreed with client (restrict access to sender service to specific users.
During runtime, check if current user is part of user list, otherwise message will be rejected
Interface-Specific User Access Lists (SP15)
Concept enhanced to sender agreements to achieve interface dependency. Assign users to a sender agreement to restrict access to an interface to specific users. Only those users can be assigned that are already assigned to the service. To specify authorized users for a particular interface of the sender, in the editor Edit Sender Agreement, choose the Assigned Users tab page and insert the users line by line. Note that the users specified for the sender agreement must match those assigned for the service, or must at least be a subset of these.
For some adapter types, it is not absolutely necessary to configure a sender agreement unless you want to make additional security settings. If you want to make access to the runtime environment dependent on the sender interface, you must define a separate sender agreement that contains the list of authorized users.
Supported Adapters:-
- XI Adapter
- Plain HTTP
- RFC
- IDoc
- SOAP
- RNIF/CIDX
- BC
- Marketplace
Now you can enforce security to avoid unfriendly attacks.
2 Comments