Can anyone Tell me if it is possible to combine SSO from Spnego and Spring security with Oauth
This is my problem :
The Client I now represent has chosen Spnego as their SSO solution.
This requires us to use a full blown appServer (Liberty) in all scenarios.
At the same time, the knowlegde and skills about Spnego in the developent team is very limited.
Due to issues with creating the keytab files, Spnego is only available in the formal test environment and not our local test enviroment.
This makes it very difficult/time consuming to test and devlop due to the long deployment time to the formal test enviroment.
Not over to my question:
If possible I would like to be able to "log in" to a service in the formal test enviroment (OAUTH2 authentication server ?) using SPNEGO SSO and get a token back that I can use in further requests towards my services located locally and/or in any other test enviroment.
Is this even possible ? I have not seen any examples where the authenticantionServer is using another sso provider to actually authenticate the user.
A different possibility might be to to do some sort of redirect from the login service in the test environment but I fear the Spnego token created only will be valid on a sever in the same domain..
I`m sorry if this question is confusing or not clear.
My knowledge of this domain (security) is limited and I struggle to get a grasp of how I can test my code locally with security enabled.
Links to any resources on the net that addresses some of these issues will be greatly appreciated.
Related
Currently working on configuring SSO for Oracle Smartview client that accesses the Oracle EPM suite of BI Tools. Pingfederate SP and Okta Idp configured with multiple AD data sources is configured.
Would appreciate if anyone would share their experience in the approach and configuration steps taken to enable SSO for Smartview
A quick Google indicates that Smart View can consume a header for a user ID. This allows you to use any standard mechanism for header injection available in your IAM environment. You mentioned PingFederate as your SP. You didn't mention if Smartview is behind any proxy (like Nginx or Apache).
Ping has a number of integration mechanisms for header injection, ranging from the various integration kits in PingFederate (Java, Apache, IIS), as well as PingAccess which is the Ping Identity standard WAM tool.
With all of the options available to you for integration, providing you step by step guidance requires more information. I would suggest a call to your Ping account team.
Getting started with Okta in a "security-conscious" organization, where connecting across the firewall requires a mound of paperwork.
Wondering if there are any best practices for testing applications internally before heading to the DMZ. There are two parts that we're primarily concerned with:
Authentication - any way we could emulate authenticating against something like an Okta preview env't without traversing the firewall?
API testing - while doing internal development, it would be great to be able to make API calls like "create user" against something that is purely internal - even if it's just a stub.
Okta doesn't currently offer a full-fledged mock Okta client, so there's no officially supported method for testing Okta locally.
There's a partial, undocumented mock-okta client here. However, it currently only supports the /oauth2/v1/authorize authorization code flow.
In spring security I understand that there are different modules catered to different usage and among some of the modules I saw LDAP, CAS and OPENID.
From my understanding
CAS - it is only used for authentication purposes based on a SSO
LDAP - it is based on a LDAP server to authenticate users and
manage them. Am I correct?
OPENID - It is also based on a OpenID Server to authenticate users
If that is the case, why would some people use CAS instead of LDAP? Maybe it is because of different usability? Can anyone shed the difference between the 3 of them why are one more preferred than the others?
CAS as a protocol is a mechanism to provide web single signon. There is also CAS, the software platform that implements that protocol amongst many others, including openid.
OpenId is also an authentication protocol, similar to CAS, able to achieve web single sign on but more in a federated fashion.
LDAP is a protocol that defines how one should talk to a directory server. Most systems use LDAP to talk to a directory to retrieve user accounts, verify them and retrieve attributes associated with them. It has nothing to do with authentication or single sign on. CAS, the software, can be configured to find user accounts from ldap, find attributes from ldap or do other things with ldap.
The basic requirement is to centralize the authentication and authorization of multiple SaaS applications to ease development (each SaaS application using minimal code to authenticate against a single source) and when necessary provide SSO. The authentication mechanism must handle the following options available to the user:
Use Third Party Authentication -- Google
Use our centralized authentication
Use the corporate provided authentication (ADFS)
In my research, I have found many, many ways this can be done and have found OpenAM to be the most complete solution, but then I came across FreeRadius which could also be used.
My Questions are:
There seems to be a plug-in for each tool where one can use the other together (OpenAM - authenticate against radius server), but is there any use case where FreeRadius would be preferred as the SOLE authentication server over OpenAM.
Does OpenAM require that a web agent installed for the server - if all I am doing is serving a Restful Interface (developed in Node.js) - is it possible to authenticate users without installing a web agent (there is no web agent for Node.js).
Can I pass user credentials from Browser -> Server (node.js) -> OpenAM thereby not giving the user the OpenAM login screen. The OpenAM token will be passed from OpenAM -> Server -> Browser (setting the cookies's origin as the SaaS's application.
That is each SaaS application server will serve as a "proxy" for user management (authenticate, authorize, and manage[create|update|delete] users)
Thank you
I'm early to the Open Identity Stack game but I am deploying an OpenAM (and OpenIDM + OpenDJ) based solution to handle exactly the solutions you mention.
direct answers:
As far as handing sole authentication over to FreeRadius I don't see why you would want to but anything is possible. Given your mention of the multiple directories (identity sources - google, ADFS, and your centralized authentication) I would think hooking up OpenAM to provide the RADIUS authentication (i.e. OpenAM RADIUS hook, not FreeRadius) would make sense.
No, a web agent doesn't have to be applied but it may make sense. There are some node.js pieces to help (https://github.com/alesium/node-openam). You just need to talk from your server to the OpenAM side (REST) and that should be good.
You can do that or you can just skin the OpenAM login screen to look like your own. I'd suggest the latter as you're then relying on OpenAM for the login screen security. If you're doing a pure proxy then you take that burden on. Your call as a design decision obviously.
good luck!
you're comparing a RADIUS sever with a Web SSO solution ... I'm not sure if this makes sense.
It seems FreeRadius does not have that many 'auth backends' (like Oauth to leverage Google Auth)
I am looking into the solution for a similar requirement myself, but I am looking to integrate 2FA as well. I have seen so many different solutions, but haven't pinned down the best one yet. Here is what I have come up with so far:
RCDev OpenID seems to be pretty comprehensive, and it is free for cases with less than 40 users.
Green Rocket's GreenRADIUS is expensive, but they have plugins for every scenario and it can work.
Red Hat's KeyCloak could be used in combination with TACACS+ or FreeRADIUS to accomplish this
Since Google lists the ClientLogin API as deprecated what is the recommended alternative?
In my case I need a server to authenticate and post things using credentials which I own. Alternatives like OAuth won't work in this context
The authentication method varies based on the scenario of your application. The scenarios reported by Google documentation are:
Login
Web Server Applications
Client-side Applications
Installed Applications Devices
Service Accounts
In your case, the Web Server Application scenario might be useful (if you give more details about what do you mean for "In my case I need a server to authenticate" I can be more precise about this point).
However, the recommended alternative to ClientLogin is OAuth2.