SOA Suite 12c OSB routing service to HTTPS basic authentication secured service - https

I am using Oracle fusion middleware 12.2.1.3.0
I am trying to create basic proxy service to HTTPS basic authentication secured service.
Can anybody explain step by step how to setup business service?
I have tried all combination but all went wrong.
Proxy service is plain with http transport. There is not authentication, security nor policy.
Pipeline is plain too = only routing to business service.
Business service transport protocol http (there are not other options allowed). URI = https://my.uri.com:443/ws/myService?wsdl
Http transport configuration = Authentication Basic, Service account = myAccount.sa (username/password)
No policies.
Business Service Testing gives me "The invocation resulted in an error: Forbidden."
When I supply username/password into testing window it gives me "Error authenticating the transport username/password: [Security:090938]Authentication failure: The specified user failed to log in. javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User specified user denied"
When I try add oracle/http_basic_auth_over_ssl_client_policy I get "Conflicts found during publish.
[OSB-387194]OWSM Policy 'oracle/http_basic_auth_over_ssl_client_policy' is not allowed since transport authentication is set to 'basic'. If you are trying to attach an HTTP Token Policy make sure that the authentication on transport configuration is set to 'None'. You can either set the authentication mechanism directly on the transport configuration page or attach OWSM HTTP Token Policy."
Any help is appreciated.
Thank you in advance.

You should not add security to BS.
In the Business Configuration tab,put the authentication to 'None' instead of Basic. You should attach security only to Proxy Service and not Business Service.
Hope it helps :)

Related

In OAuth2 flow, can we delegate authentication to Windows SSO

We have an in-house OAuth2 server used by our applications. Now we want to use Windows SSO for our applications but without them to change anything: they'll still reach our OAuth2 server for an access token and the authentication part will be delegated to Kerberos (which Windows use, if I understood properly).
Is there a way to do that?
That is a standard setup and should just require configuration changes in the Authorization Server (AS) - with zero code changes in applications.
Most commonly:
The AS might be hosted in the cloud
It will redirect browsers to an on premise Identity Provider (IDP)
The IDP can connect to Active Directory
You may also need a fallback option for when users are not joined to the work domain. See this Curity guide for an example and some infrastructure factors to think about.
If the AS is in house it may even be able to make a direct Kerberos connection via an LDAP data source, though the preferred architecture is a separate IDP.
Of course you need an AS that supports the ability to make this type of connection, so would need to check the vendor docs.
REQUEST FLOW
Kerberos has always been the simplest protocol conceptually but the deepest to understand - here is a bit of a summary:
Your apps will make a standard OpenID Connect authorization redirect to the AS
The AS may then present an authentication selection screen to the user, unless there is only a single option
Alternatively an app can send the acr_values query parameter to say which authentication method to use
The AS will then redirect the browser to the next stage of processing, that uses a 'Windows SSO authenticator'
The redirect to the Windows SSO authenticator does not have to use OpenID Connect - it could be any vendor specific HTTP request
The browser will send an encrypted Kerberos ticket automatically by connecting to AD - a prerequisite for this to work might be that the domain in the URL is in the Local Intranet zone on end user computers
The Windows SSO authenticator will need to be able to decrypt this credential, which typically requires a Service Principal Name to be configured
Once the Kerberos ticket is decrypted, the authenticator will make an LDAP connection to an Active Directory data source via its standard LDAP endpoints, to verify the received ticket

Authenticate Nifi using OpenID Connect using API

I am new to OpenID connect & security domain. I have configured Nifi to use OpenID for authentication using online documentation. And to automate a few nifi related tasks we are using nipyapi.
I have already written python code which does automated flow deployment for basic nifi installation (unsecured & without user authentication)
Now, I have to move the code to secured Nifi installation. How to authenticate to OpenID connect using nipyapi/rest API ?
AS per discussion with Bryan, i am planning to use client certificate for authentication but it started giving authorization error. and have created another question with the details.
Nifi - Client Certificate Authorization Error
OpenID Connect generally requires that you follow a flow of re-directs, typically in the browser. NiFi re-directs you to the login page of the OIDC provider, upon completion, the OIDC provider redirects you back to NiFi. I'm not exactly sure how, or if you even can, perform this login process from scripts. An easy alternative would be to just generate a client certificate to represent an automation user for any NiPyApi scripts. Client certificate authentication is always enabled by default for NiFi.

Access restriction of WEB API service call based on request

When we access the WEB API service methods from a web application through Ajax calls, will there be any access restrictions for the following scenarios
“HTTPS” Web application accessing an “HTTP” WEB-API
“HTTP” Web application accessing an “HTTPS” WEB-API
Will there be any impact on request application or context, either it Http or Https the web API will behave same.
Please advice.
When you trying to access the "HTTP" Api or any service from the HTTPS or SSL enabled client, then the security itself is compromised.
SSL certificate is enable to maintain the higher level of security, in any HTTPS enabled client, when you access the Non SSL or HTTP ApI then you have to specify the Transport layer explicitly to allow the process of data [example IOS client - Application Transport]
Even if you have requirement to access the HTTP API, please go through this reference.
Make Https call using HttpClient

Forward SPNEGO Credentials to Secure Cluster

I have a cluster secured by Kerberos, and have a REST API that needs to interact with the cluster on behalf of the user. I have used Spring Security with SPNEGO to authenticate the user, but when I try to use the Hadoop SDK, it fails for various reasons based on what I try.
When I try to use the SDK directly after the user logs in, it gives me SIMPLE authentication is not enabled.
I have noticed the session's Authenticator is UserNamePasswordAuthenticationToken which does not make sense, since I'm authenticating against the Kerberos realm with the credentials from the user.
I am trying to use this project out of the box with my own service account and keytab: https://github.com/spring-projects/spring-security-kerberos/tree/master/spring-security-kerberos-samples/sec-server-spnego-form-auth
For what it's worth, you can leverage Apache Knox (http://knox.apache.org) to consume the Hadoop REST APIs in a secured cluster. Knox will take care of the SPNEGO negotiation with the various components for you. You could use the HTTP header based pre-auth SSO provider to propagate the identity of your enduser to Knox.
Details: http://knox.apache.org/books/knox-0-8-0/user-guide.html#Preauthenticated+SSO+Provider
You will need to ensure that only trusted clients can call your service if you are using that provider however.
Alternatively, you can authenticate to Knox against LDAP with username/password with the default Shiro provider.
One of the great benefits of using Knox this way is that your service never needs to know anything about whether the cluster is kerberized. Knox abstracts that from you.
First of all, Spring Sec Kerberos Extension is a terrible piece of code. I have evaluated it once and abstained from using it. You need the credential of the client authenticating to your cluster. You have basically two options here:
If you are on Tomcat, you can try the JEE pre-auth wrapper from Spring Security along with my Tomcat SPNEGO AD Authenticator from trunk. If will receive the delegated credential from the client which will enable you to perform your task, assuming that your server account is trusted for delegation.
If the above is not an option, resort to S4U2Proxy/S4U2Self with Java 8 and obtain a Kerberos ticket on behalf of the user principal and perform then your REST API call.
As soon as you have the GSSCredential the flow is the same.
Disclaimer: I have no idea about Hadoop but the GSS-API process is always the same.

Credential Provider communicating over network

First let me explain my desired solution:
I'm making a custom Credential Provider to authenticate a user by sending logon credentials to an external authentication server, then passing the same credentials along with some extra authentication parameters back to the Credential Provider. The Credential Provider then sends these credentials to the Local Security Authority which in turn authenticates the user based on a custom Authentication Package.
I am quite new to programming in Windows, but I've been studying the Credential Provider Technical Reference, so I have some understanding of how it works. What I haven't figured out yet is this: when programming a custom Credential Provider, can I program it to communicate externally like proposed in my example above? I have read somewhere that I can use WinHTTP to send data to and from the Credential Provider. Is this correct?
Regards,
bagzera
First you need to implement the IConnectableCredentialProviderCredential interface which provide a function which called Connect (this method will be called just before GetSerialization) so in this function you can make a connection to your authentication server
I have written such provider before. There is no problem in using WinHTTP to communicate with external entities. You might run into some issues with HTTPS if you have unsual SSL requirements. All you need to do is to load certificates into the correct stores.

Resources