Browse Prior Art Database

Mechanism to handle connection, login and authorization issues in server client architecture

IP.com Disclosure Number: IPCOM000239500D
Publication Date: 2014-Nov-12
Document File: 4 page(s) / 105K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is method to automaticaly handle authorization issues between software components in client server architecture

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 4

Mechanism to handle connection , , architecture

There are a number of reasons that causes client application login and authorization problems on server-client architecture and support teams around the world tend to spend considerable amount of their time investigating and troubleshooting this kind of problems:

Logging to application can be established on many levels and varieties of methods are used to validate user, which makes the problem even harder:
- central users repository - e.g. LDAP
- local operating system
- product own users repository

Add to this additional set of problems caused by validating user permissions and roles (in application or in system) and we have a really good reason for complex solution

To summarize the problems may involve among other
- incorrect credentials
- network (e.g. firewalls)
- system configuration (incorrect entries in /etc/hosts)
- application configuration (e.g. client has not been re-configured after server has been moved to different host/port)

- lack of required permission per users role

The know solution involves (to some extend)

- Single sign-on systems (which greatly simply dealing with multiple accounts, but does not offer any particular method to troubleshoot connection problems)

- https://www.google.com/patents/US6587853

Following disclosure describes solution how to overcome login and authorizations issues between a client and server machines.

The proposed solution activates only when there is a problem reported by the client therefore this is not a "key to the castle" model. It does not create any vulnerability against DoS (Denial of Service)

The solution we propose is a special server (Resolver) which will be established always at predefined location (e.g. given by known hostname and port combination)

    On the machine where client is installed there will be also installed resolver agent - the resolver agent may be a shared component/private component or it can even be embedded in the application client itself

    In case client is not able to establish a connection with server - it requests resolver agent to perform the troubleshooting activities.

1

login and authorization issues in server client

login and authorization issues in server client


Page 02 of 4

    Resolver agent will start with embedded troubleshooting scenarios (e.g. check network configuration/use traceroute/ etc) to determine and fix the problem. If the problem cannot be fixed and resolver agent is able to connect the resolver it will retrieve from the server additional scenarios

Those scenarios may be more complex up to the point when resolver negotiate

with application server granting entry for a client (including resetting password if needed/ creating an account, etc)

    Some of the scenarios may be general, but most of them the scenarios will be registered per application server and/or application client.

    Resolver agent will perform most of its task automatically on behalf...