Proposal of Generic ReponseForwardHeaders - Can be used for new

Hi,

I would just like to highlight the following, which I think we could look
at addressing properly and generically across the board.

With regard to the new proposal stand as of march for authentication
session identification,
my understanding is that is drive from the webbrowser client and the server
just accept id provided. It is no longer driven from the server.

I would pref an approach were by it is drive from both client and server,
which means still ensure
that more difficault for hacking, can't just run tought all possible
permutation of client identification tokens and bruteforce ones way into
end system.

As one of my previous emails to the group was for an approach from driven
from server side to client side, which is not that easy to hack and looking
up of session token, versus encryption and description payload, potentially
could be faster, given url and things have max lengths.

Therefore I would like to propose that we look at implemented generic
response forward headers,
which can be used for server side to client driven session management and
also for the very old school redirect problems, using the Location header
for security. With microservice were one ones single world to handle all
the PCI credit cards and banking information for accounting purposes. It
because increasingly nessary to do hand overs into those worlds, to ensure
high level of security compliance is hand by a single team and all auditing
is in one place for critical information. Which allows design a generic
journey into such infrustature for anyone.

Below is example of the problems that live every where, which we could
generically address with the propose of this simple json self description
example benefit this line:

Request->Server
Response<-Server
Payload of Repsonse...
Headers: ForwardRequestHeaders
{
RegRequestPathPattern:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification(Allow Passing/Deny) (should be
explicit enable only)
]
},
RegRequestPathPattern2:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification (Allow Passing/Deny)(should be
explicit enable only)
]
}
}


-------

The insatitial page/api auth redirect, that looks up the subscriptionId and
generates AuthToken,
Then according to the following containing controls will have to perform
the redirect mechanism in the following way.

I would recommend, to avoid being tripped up any browser, react something
not support or being bugged that
We should just support looking for the param in all places, url, query
string, headers, body, form-body submission.
This way we can use the best redirection mechanism possible, that the
client channel supports.

Remember that the url has a limited length, so placing jet tokens, which
can contain a lot more information in the url, can eventually hit the maxim
url length limit.

1. Hand over from different channels to PCI world:

*a. Breakout (Web Browser) (App)*
- Opens Url to instatial page.
- Performs the redirect using url with path, query params. (contents public
visible) url has limited length.
- (Url/Visible) Header:Location URL, can’t specify forward headers, all
must be in the url
- (Url/Visible) HTML meta refresh tag, all in the url
- (Url/Visible) javascript window.location, all must be in the url.
- (Form-Body/Hidden) render a html webpage and then client side generate a
form that is automatically submitted.
- Else render an html webpage and generate a form that is automatically
submitted

- Proxy the request, by acting as pass sought middle man ( but this is not
secure, as opens the door, middle proxy reading the encrypted contents and
fact proxy needs show correct certificate details and spread security now
across many layers, complicating management and much higher risk, not
contained within a single squad, multiple squad have then share security
responsibility.
Therefore, this is not a method that we like to do.

**If the landing page was to redirect again, then the URL/Visible, could be
concealed, because after landing page converted to session state cookie.


*b. WebView( App)*
- Performs the redirect with any one of the methods in a above breakout
(browser)
- (Url+Headers/Hidden)Request from instatitital page/api auth redirect,
which returns the auth information in the Repsonse,
which we then add the information as headers to the web view url open
request, which react supports, to open the page.
** Benefits there are no flashing pages in the redirect  using instatital
pages as for breakout in a above, looks seamless.

*C. ClientBrowser (Online)*
- One of the methods above in a.
- Even if in a frame, the same problems persist.
- The only other approach is to use background request and javascript to
re-write the contents of a html page element place holder, this is a web
app client service side typically type workflow/mechanism approach. ( more
complex)



So I would recommend that if you written a generic landing page that be
able to pulled the specified params from both url path+query string, form
body and headers.

I basically have suggested this for authentication purposes, however, might
as well expanded to to be more generic.
In which can Header:location, can specific request headers under a Repsonse
header called.

ResponseForwardRequestHeaders
{
RegRequestPathPattern:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification
]
},
RegRequestPathPattern2:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification
]
}
}


Kind Regards,

Wesley Oliver


-- 
-- 
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Skype: wezley_oliver
MSN messenger: wesley.olis@gmail.com