Skip to content

authorize

moh-hassan edited this page Mar 16, 2024 · 6 revisions

Authorization

The authorization process verifies whether you have permission to access the data you want from the server. You may include parameters of authorization to access OData. OData2Poco provides authorization types that make it easy for you to handle authentication protocols.

The supported authorizations are:

  • No Auth
  • Bearer Token
  • Basic auth
  • OAuth 2.0
  • Windows NTLM authentication.
  • Microsoft Digest authentication.
  • Integrated Windows Authentication, enabling users to log in with their Windows credentials.

Note: OAuth2 is supported by o2pgen v3.1.0+

Bearer authentication

A bearer token is a security token. Any user have a bearer token can use it to access data resources without using a cryptographic key.

To use a bearer token: Use Authentication type token with the option (-o token). Enter in the commandline the value of the token as a password parameter using the short/or long options:

    -p eyJhbGciOiJSUzI.. -o token
    #Or
    --password eyJhbGciOiJSUzI --outh token

The library pass the token to the headerRequest of HttpClient

Basic Auth

Basic Auth is an authorization type that requires a verified username and password to access OData resource. To use Basic Auth:
Enter the value of the username as and the password parameter:

  -u username -p password -o basic
  --user username --password mysecret --outh token

OAuth 2.0

OAuth 2.0 is an authorization type that enables you to connect to OData service without exposing your password. OData2Poco uses the standard OAuth 2 two-legged authentication process, which proceeds as follows:

Obtaining a token using two-legged authorization is done by Sending a call to the OAuth2 Token server by specifying your client credentials data, and the Token server will return access_token.

The client credentials data are:

Client_id 
Client_secret
grant_type: client_credentials

To use the OAuth 2.0 authorization: You have to pass the following parameters:

  • The client_id using the option -u , --user
  • The client_secret using the option -p, --password
  • The Token endpoind through the option --token-endpoint
  • The Token parameters through the option --token-params.

The Token params are key/value pair parameters(without client_id, client_secret because they pass as described above). Each pair is in the form key:value and they are separated by '&' and may include resourse /scope/tenant/...

      resource=https://url/to/resource&option1=...

For example:

  --token-params "resource=https://myorg.dynamics.com&audience=http:/my_app" 

OData2Poco connects to the token endpoint (Oauth2 server) and require access_token based on these parameters. The endpoint reply with access_token which is then paseed to the OData service.

If you get an access_token (for example using postman), you can pass it as a password option and you need not to pass client_id,client_secret,Token endpoind and Token params

Example1: using Oauth2 authentication:

For OData service of 'Dynamics 365 for Finance and Operations' Use the following PowerShell script:

In PowerShell

# Oauth2 example	
# Set the value of options
$resource='https://abc-123456devaos.cloudax.dynamics.com'
$url="$resource/v1.0"
$tenant="e6gaaf8f-c0ef-4c1d-0052-a05006cc86b9"
$client_id="710bad1c-1d5g-4ecc-8fac-34994f5002b0"
$client_secret="MNOpq23LGZ6SP8fCGJrCnvqp2/EmlhFr11mVaQsMvL9"	
$token_endpoint="https://login.microsoftonline.com/$tenant/oauth2/token"
set token-params="resource=$resource"
# run the command
O2Pgen.exe -r $url  -o auth2 -u $client_id `
-p $client_secret  `
--token-endpoint $token_endpoint  `
--token-params $token-params  #other options

Note: use the symbol backtick ` to concatenate the arguments.

Example2: using Bearer authentication

If you have the access_token or get it in postman tool, you can use it as a password option:

In PowerShell

$token='aaa-bbb-cccee'
$url='https://abc-123456devaos.cloudax.dynamics.com'
o2pgen.exe -r $url  -o token -p $token

Example3: using Basic authentication

If you Access server using basic authentication with user and password :

In PowerShell

$user='aaa-bbb-cccee'
$password='secret'
$url='https://abc-123456devaos.cloudax.dynamics.com'
o2pgen -r $url  -o basic -u user1 -p $password

Example4: Windows NTLM authentication

$url='https://abc-123456devaos.cloudax.dynamics.com'
o2pgen.exe -r $url  -o ntlm -u username -p password `
 --domain your_domain

Example5: Microsoft Digest authentication

Enter the Following parameters:

      -o digest -p token 

Example6: Integrated Windows Authentication

If you are logged to the windows domain Active Directory, you can login without passing login parameters. By default

o2pgen.exe -r $url -o none
#or without option -o
o2pgen.exe -r $url 

Securing password

To avoid passing password in the commandLine argument, store it in Environment variable and use it instead: example

--password %PasswordVar% in Windows

--password %PasswordVar% in Linux/MacOs

OS auto resolve these environment variables in the commandline and o2pgen read it.

Testing Environment:

O2pgen in OAuth2 is tested with the following service:


Allow setting of SSL-TLS protocols

The option `--ssl', enable the specified TLS protocol when making HTTPS requests.

Allowed Valid values are: Tls, Tls11, Tls12, Tls13. By default, all available protocols are enabled. Note that enabling older, less secure protocols like TLS 1.0 or TLS 1.1 may pose a security risk. Consult with your system administrator or IT department if you're not sure which protocol to use.

Example

Enables TLS 1.2 for HTTPS requests.

o2pgen.exe --ssl tls12

Example

Enables TLS 1.1 and TLS 1.2 for HTTPS requests.

o2pgen.exe --ssl tls11,tls12

Note:

Users may need to run the command prompt or terminal window with elevated privileges (i.e., "Run as administrator") in order to use the --ssl option, depending on the security settings of their system.

When this option is useful

Enabling specific TLS protocols can be useful in certain situations, such as:

  1. Encountering compatibility issues: Some servers or clients may be configured to use older TLS protocols that are not compatible with newer protocols. In this case, you may need to enable an older TLS protocol, such as TLS 1.0 or TLS 1.1, in order to establish a connection.

  2. Compliance with security policies: Some organizations may have strict security policies that require the use of specific TLS protocols. In this case, you may need to enable a specific TLS protocol in order to comply with these policies.

  3. Performance optimization: In some cases, enabling specific TLS protocols can improve the performance of your application by reducing the overhead of the TLS handshake. For example, TLS 1.3 introduces a number of performance optimizations that can reduce the latency and improve the throughput of HTTPS requests.

Note that enabling older, less secure TLS protocols like TLS 1.0 or TLS 1.1 should be done with caution, as it can make your application vulnerable to security threats. You should only enable these protocols if you have a specific need to do so, and you should consider upgrading your server or client software to support newer, more secure TLS protocols.


Allow to Skip Certification Check in http connection

The help text:

-S, --skip-check                   Skips certificate validation checks that include all validations such as trusted root authority, expiration, ... .

Ignore SSL certificate errors when making HTTPS requests. This option can be useful for testing or when connecting to a server with a self-signed certificate. Use this option only when you're sure that you trust the server you're connecting to, and you understand the implications of ignoring SSL certificate errors. When this option is useful:

  • This option can be useful for testing or when connecting to a server with a self-signed certificate.

  • This option should not be used in production environments (except you trust the server)

  • If you're not sure whether you should use this option, consult with your system administrator or IT department.


Allow to specify Http header in Odata http connection with the computing of base64

The New option: --http-header or -H enable to pass http header to httpClient. Http Header as a list of key/value pair separated by ';' e.g. key1:value1;ky2:value2.

Example

This example show how to pass Bearer token for Authorization and extra headers. (Note that auth is none).

o2pgen --url http://localhost/odata --auth none ^
--http-header "Authorization=Bearer %token%";key1=123;key2=abc

Also, header can be entered using the repeating option like:

On Windows:

 -H "Authorization=Bearer %token%" ^
 -H key1=123  ^
 -H key2=abc

On Linux/Mac:

 -H "Authorization=Bearer %token%" \
 -H key1=123  \
 -H key2=abc

See Also

Using Proxy Server

Clone this wiki locally