I used OWSM policy Oracle/wss_http_token_service_policy on the rest based proxy service, it is working fine (authenticating with basic.credentilas) in my local machine weblogic server but not supporting in the dev/test server, so what extra setting is required here? or do we need to use any other policy, I want to use just the basic authentication configured in my realms. Could you please advise.
Related
I am running a web application packaged as WAR inside WildFly, with authentication configured via a secure deployment managed by the Keycloak adapter subsystem.
The corresponding client in Keycloak is configured with a service account. Now, I'd like to send requests to Keycloak (and possibly other services) using the service account and associated roles.
What is the best way to obtain a token for authentication "as the service", i.e. using the service account?
Is there a way to access the client secret specified in the secure deployment definition from the runtime context of my WAR?
Am I doing things wrong? What is the optimal approach here?
Note that I still need to be able to authenticate requests from the web inbound to the service with Keycloak.
Is it possible to do federated identity between multiple instances of IdSrv3 using OpenID Connect/OAuth2 in the following scenario?
Multiple instance of IdSrv3, called Local STS, running on different machines with some kind of chain of trust to a Central STS. The machines running the Local STS can go offline and in that context the applications running on the local machines makes call to local STS for a token and uses that token while communicating with APIs on another server. The API Service, which is registered and connected to the Central STS, can validate and trust the token generated by a Local STS. Is it possible to do this setup with IdSrv3 or IdSrv4? Also how can a chain of trust be established between central and local STS?
That is absolutely possible -
in IdentityServer you can add external providers via ASP.NET (Core) authentication middleware. For the "other" IdentityServer this becomes a normal client.
https://identityserver.github.io/Documentation/docsv2/configuration/identityProviders.html
I have a project that have embedded jetty with SPNEGO enabled. I would like to be able to run this project locally for development purposes (WITH SPNEGO enabled!)
My question is, is the SPN and keytab associated with a particular server at all or can I use the same set on multiple instances of my service?
Kerberos requires that both the client and server somehow figure the service principal to use without any prior contact. If you have control of both the client and server, you can use any principal you want provided you configure both sides to
use the same principal.
In the SPNEGO case, the client does the "standard" thing and builds a principal based on the hostname of the server. (i.e. I want to talk to www.foo.com, I'll try
requesting an HTTP/www.foo.com service ticket and see if the server accepts it. )
I don't know of any way to get the SPNEGO code in the browser to use a fixed service principal. So in this case you'll need a separate keytab for each server.
Our IT staff refuses to install the SiteMinder agent on our application's IIS 6.0 web server, citing security concerns as it is a third-party software, as well as the possibility of high resource utilization impacting application performance.
They suggest that we set up an independent, segregated web server containing only a bare-bones IIS, the SiteMinder Agent, and a "shim" to authenticate login attempts.
This shim would be a single ASPX page marked to be protected by the agent. It would use the SiteMinder agent to authenticate the user ID, look up the user ID in the application's database, and return the user ID and password to the user's browser. A JavaScript function would then POST the user ID and password to the application's existing login page as if they typed it in themselves.
Are their concerns warranted? Why or why not?
Have you ever heard of anyone implementing a similar architecture?
Is their proposed solution good, bad, or ugly?
It does not look like it would work, because the agent manages not only the initial login, but subsequent calls to the application, i.e. authenticated session. The agent examines the cookie, validates it, etc. Your scenario does not describe how that would happen.
In our environment, all internet traffic goes through an Apache reverse proxy before hitting IIS. IIS is behind firewall. The Apache reverse proxy has the SM agent all it does is redirect the traffic to IIS. I suppose it would be feasible to do a similar setup with IIS acting as a reverse proxy.
BTW, tell your IT guy that his proposed shoestring and bubblegum login solution is a much bigger security concern than installing SiteMinder on IIS.
The apache reverse proxy solution will definitely work, but with SiteMinder r12.51, Secure Proxy Server is included, which is basically SiteMinder's version of a reverse proxy (plus a lot more).
SPS will let you configure a single server as a "gateway" for all of your applications that can't or won't install a SiteMinder agent. The web agent is embedded in SPS and a proprietary Java app does the heavy lifting. SPS also has a GUI which follows the look and feel of the r12 WAMUI, which makes configuring it very simple.
Secure Proxy Server also has a Federation Gateway feature, so you don't need to install the web agent option pack if you are doing SAML Federation. All of your fcc pages can also be served by the SPS, so you can reduce the number of webservers needed to support your SSO environment.
I want to make Portofino a partnerapp for josso, and i did the steps described here: http://www.manydesigns.com/documentation/tutorials/integration-with-josso.html,
but I don't know how to connect josso with portofino because they use different servers.
JOSSO has two parts: gateway and agent.
Gateway can be installed anywhere (and should be configured with a specific datastore), but agent should be installed on all servers that consume JOSSO authentication. JOSSO agent installs its hooks on web servers to control access.
So, you should install JOSSO agent on the web server instance that portofino runs on.