PASOE: access to the HTTP Authorization header from web hand

We intentionally blocked the authorization headers to PASOE, but we return them back from the WebHandler to the client. Which one are you trying ?

I’m trying to get the Authorization header I’m receiving in the query. I need at least the user id usually extracted from the header, and it would be nice to have the complete header to get the password also.

In my WebHandler, I am able to return Authorization header.

This is the code in my Webhandler where I am trying to return a JWT token

oHeader = NEW OpenEdge.Net.HTTP.HttpHeader('Authorization','eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ').

       ASSIGN

           oResponse:Entity        = oBody

           /* HTTP messages require a content type */

           oResponse:ContentType   = 'text/plain':u

           /* ContentLength is good too */

           oResponse:ContentLength = oBody:Size

           .

       oResponse:SetHeader(oHeader).

I get that back when I invoke the WebHandler

curl http://localhost:3940/web/test -v

* About to connect() to localhost port 3940

*   Trying 127.0.0.1... connected

* Connected to localhost (127.0.0.1) port 3940

> GET /web/test HTTP/1.1

> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

> Host: localhost:3940

> Accept: */*

>

< HTTP/1.1 200 OK

< Server: Apache-Coyote/1.1

< Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

< Content-Type: text/plain

< Content-Length: 4

< Date: Tue, 26 Sep 2017 21:23:53 GMT

Connection #0 to host localhost left intact

* Closing connection #0

In-case you want to pass the Authorization header to WebHandler so that you can invoke a HTTP request, then I would suggest using some other header name and you should be able to get the header in the WebHandler using poRequest:GetHeader(<your header name>) whose value can be passed in the Authorization header for the HTTP request.

Hi Irfan,

You said you intentionally blocked authorization headers to PASOE, which explains why we can't access "Authorization" header from WebHandler. In our case we would like to use the received JWT tokens on the calls that are made from PASOE to other services. We were going to keep Authorization header in session and then set it to web request right before making call to another service. Since it's not available, how can we do it?

Thank you

Ok, so it is not possible to use 'Authorization' as a header when using webhandler?

I saw another answare ron this issue, so I changed the header to something else...

For OAuth2/JWT SSO support, the Spring Spring layer will populate the Client-Principal (delivered to the ABL application) with a validated JWT's payload claims.  In your application you can access the JWT claims without parsing the JWT yourself, which ensures that the claims used by the Spring Security layer are also those used by your application.

You also have the option of passing the full HTTP request Authorization header's JWT as a Client-Principal property "token_value" when you configure 'OEClientPrincipalFilter.forwardToken=true'.   If present, the Client-Principal property 'token_value' can be used to build the Authorization header's 'bearer' scheme and downstream SSO to another OAuth2 resource.

[mention:96ac66c56cc24edba29a9cf865c9c3f5:e9ed411860ed4f2ba0265705b8793d05] that's good news! From which OE version is this supported?

[mention:96ac66c56cc24edba29a9cf865c9c3f5:e9ed411860ed4f2ba0265705b8793d05] that's good news! From which OE version is this supported?

I found the JWT/OAuth2 configuration in 11.7.5, and I would not try any version earlier than that.

The 12.x releases have the same basic functionality as 11.7.5, but use Spring libraries at a higher patch level.

Obviously we'd like you to move to the version 12.1 release and take advantage of new OE capabilities.  But if you are just getting started doing research in the OAuth2 space the 11.7.5 could be an alternative starting point.