I am using ServiceNow REST API calls to get ServiceNow records inside my application. My application takes username,password and domain url of their servicenow account from the user to do this. I have this situation where one of my client uses OneIdentity SSO for their servicenow application. How can I make REST calls in that case?
I should be asking them to provide a local account credentials instead of SSO credentials or is there anyway I can bypass the REST calls with SSO ? If so how ?
I should be asking them to provide a local account credentials instead
of SSO credentials
Yes, web services are not authenticated in the normal way people use to log in to the system, all of them are using the basic HTTP authentication (even if you are using the SSO URL to call the web service)
References: Service now community URLs [1] [2] & My tests using Postman :)
Related
I'm building a microservice based REST API and a native SPA Web Frontend for an application.
The API should be protected using OAuth2.0 to allow for other clients in the future. It should use the Authorization Code Flow ideally with Proof Key for Code Exchange (PKCE)
As I understand it I need to run my own OAuth Auth Server that's managing the API Clients and generating access tokens, etc.
Also I need my own Authentication/IAM service with it's own fronted for user login and client authorization granting. This service is the place the users login credentials are ultimately checked against a backend. That last part should be flexible and the backend might be an LDAP server in some private cloud deployment.
These components (Auth Server and IAM servicve) are outside of the OAuth scope but appear, correct me if I'm wrong, to be required if I'm running my own API for my own users.
However creating these services myself appears to be more work than I appreciate besides the obvious security risks involved.
I read about auth0 and okta but I'm not sure if they are suited for my use case with the application potentially deployed in private cloud.
I also thought about running Hydra (OAuth Server) and Kratos (IAM) by ory but I'm not sure if this is adding too many dependencys to my project.
Isn't there an easy way to secure an API with OAuth that deals with the Auth Server and the IAM that's good for small projects?!
I have a Java app running under Websphere Liberty on IBM Bluemix. I need to be able to authenticate users 3 different ways - Basic Auth, SAML SSO, and OpenAuth SSO, in that order.
I can set up the app to do Basic Auth (using custom code) or SAML SSO (using the Bluemix Single Sign On service), but can't figure out a way to configure it to handle both at once. (I haven't even looked into how to do OpenAuth yet.) If I configure the app to use the Bluemix SSO service, then my app never sees the incoming requests to check for a userid and password to try Basic Auth before the SSO service grabs it.
I tried changing the redirect URL in the SSO service to an endpoint inside my app, but then all I get is
CWOAU0062E: The OAuth service provider could not redirect the request because the redirect URI was not valid. Contact your system administrator to resolve the problem.
I can't be the only one that needs to do this. Can anyone tell me how they did it?
The scenario is this: 1. There is a web application with a browser UI. 2. User has to log in to the Web UI. We would use Shibboleth for authentication (SSO) 3. The application connects to various backend components via REST API's 4. We are considering the REST API's are hooked with Shibboleth through the Shibboleth Service Provider
Once logged in the web app should pass the use context (session) to the REST API.
Is this scenario supported by Shibboleth? What is the best way to pass the session context to the REST API so that it validates the session through its service provider?
I want to implement SSO using Thinktecture Identity Server V3. The applications the I want to use this SSO are asp.net MVC apps. I was going through samples provided on the thinktecture wiki and am able to see two approaches:
1- Resource owner(providing credentials through application and calling Identity server using OAuth2Client Apis)
2- Using Owin middleware(Startup class) to call the Identity server.
In my case I wanted to calling Identity server login, but without using Owin. Do you any hints/sample on how to do that.
Thanks
If you don't want to use the Microsoft OpenId Connect middleware (and as a result OWIN) in your clients, you could initiate the login flow yourself by redirecting the user to the authorize endpoint.
Authorize endpoint: http://thinktecture.github.io/Thinktecture.IdentityServer.v3.Documentation/docs/endpoints/authorization.html
They guys behind IdentityServer have a client example showing some of the concepts if you want to handle it all yourself:
https://github.com/thinktecture/Thinktecture.IdentityServer.v3.Samples/blob/master/source/Clients/MvcFormPostClient/Controllers/AccountController.cs
We are designing security for a green field project with a UI web module (Spring MVC) - the client, and a RESTful services web module (CXF) - the server, to be deployed as separate war files in the same Websphere app server. The system should be secured with Spring Security, authenticating against LDAP and authorizing against a database. We have been looking for the best solution to share the security context between the 2 apps, so a user can authenticate in the web UI and invoke its AJAX calls to the secured RESTful services. Options found:
OAuth: seems overkill for our requirements, introduces a fairly complex authentication process, and reportedly some enterprise integration issues
CAS: would amount to setting up an enterprise SSO solution, something beyond the scope of our engagement
Container-based (Websphere) security, although not recommended by Spring Security, and we're not clear if this could provide a solution to our specific needs
We're looking for a simpler solution. How can we propagate the Security Context between the 2 apps? Should we implement authentication in the UI web app, then persist sessions in the DB, for the RESTful services to lookup? Can CXF provide a solution? We read many threads about generating a 'security token' that can be passed around, but how can this be done exactly with Spring Security, and is it safe enough?
Looking forward to any thoughts or advice.
You want to be able to perform the REST web services on the server on behalf the user authenticated in UI web module.
The requirements you described called SingleSignOn.
The simplest way to do it is passing the HTTP header with the user name during REST WS calls.
(I hope your REST client allows to do it).
To do it in secure way use one of the following:
Encrypt the user name in REST client and decrypt it in REST server
Ensure that the header is sent from the local host (since your application deployed on the same container)
Therefore, protect both application using SpringSecurity authenticate against LDAP.
In the first application (Rest Client) use regular Form Authentication
In the second application (Rest Server) add the your own PreAuthenticatedProcessingFilter:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#d0e6167
Edited
The “Authentication” is the process of verifying of a principal’s identity.
In our case both REST Client (Spring MVC application) and REST server (CXF application) verify an identity against LDAP. LDAP “says” OK or Not. LDAP is a user repository. It stateless and does not remember the previous states. It should be kept in applications.
According to my understanding, a user will not access directly to REST server – the user always access REST Client. Therefore, when the user access REST Client he/ she provides a user name and a password and REST Client authenticate against LDAP. So, if REST Client access REST server the user is authenticated and REST Client knows his name.
So, if request come to REST server with a user header name - REST server for sure knows that the user was authenticated and it should not authenticate it again against LDAP.
(The header should be passed in the secured way as described above).
Rest Server should take the user name, to access to LDAP and to collect related user information without providing of the user password (since the user already authenticated).