I require help on integration of web service with JOSSO for authentication.
Whenever a request comes from SOAP UI(client) to service, it should be authenticated against an Active Directory server, and if it succeeds then it should hit the service endpoint.
After a long struggle, we came to know JOSSO exposing their login methods as web services also.
But for authenticating against AD, you have to make least two or three web service calls.
Get Assertion Id by passing Username & Password.
Get Session Id by passing Assertion Id.
Get Role information by passing the Session Id.
Just for testing, you can download this wsdl as a project in to SOAP-UI tool and hit to get response.
JOSSO WEB SERVICES WSDL LINK
You can find the same from source code also:
\josso-1.8.3-src\components\josso-ws-v1_2\src\main\wsdl\josso-1.2.wsdl
Related
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 :)
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?
We are starting a project for SSO and using wso2 to do all SAML , OAuth and keep our Webapplications as service providers.
I have been through the online documentation but need some help .
When user tries to Access to any resource in our webapplication i would send user to wso2 to get Authenticated in case of OAuth /openid connect , how would i form this url ?
I have configured IDP and SP in WSO2 console, after authentication how does WSO2 give credentials of authenticated users to service provider , i see as per document or sample app , this should be SAML or any other sso protocols like oauth etc. documentation is not clear or any examples i can find
i want to redirect the user after OAuth or SAML with my own created Authn cookie , what is the provision for that .
any help would be appreciated
Yes, You can configure your application as service providers and wso2 IS as Identity provider.I guess, You can implement saml sso for your scenario and its simply documented here.There is another blog which describe the same configuration
You can download travelocity sample code and war file .Analysing the code you can get some idea about implementation.
By following above blogs, You can implement the complete SSO flow.
Q. > When user tries to Access to any resource in our webapplication i would send user to wso2 to get Authenticated in case of OAuth /openid connect , how would i form this url ?
Answer :
https://localhost:9443/oauth2/authorize?response_type=code&client_id=wCmphfs69oaN3JhqO3d9FFgsNCMa&scope=openid&redirect_uri=http://localhost:8080/Samplespapp/googleauth.jsp
client_id : is that if which we get on UI oof wso2 console after we finish configuring Service provider in my case i configured Inbound Authentication Configuration as OAuth open id .
redirect_uri is the url where we want to go after authentication , this should match callbackback url in View/Update application settings
Answer 2: I still dont see any valid reason why inbound authentication has to be sso protocol but this is how wso2 works , to put it in laymans term i have a client to connect to using SAML and Other OAuth . i opt for a SSO vendor who takes that headache from me to implement SSO protocols but i Still have to implement atleast one SSO protocol as after SSO handshake wso2 has to communicate userX with role as Admin to service provider app this is done again using SSO !!
ping federate makes it simple it makes an encrypted request header that had data in key value pair. may be i am not understanding but i dont like this inbound Authentication in SSO .
Q. 3.>i want to redirect the user after OAuth or SAML with my own created Authn cookie , what is the provision for that
documentation is poor in this area just some java classes but no end to end example , every one will point to travelocity .
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).
I have a web application (gwt) that is running on a tomcat application server. This web application consumes several web services (login, application data transfer, queries, etc.). The web service client on the tomcat is implemented as apache axis2 web service client.
For user log on I provide a form in the web application with username and password. This data are transmitted via web service to authenticate the user.
It is planned to change the hole authentication mechanism to client certificated based authentication. The authentication still should be done on the web service provider side.
So my system has three relevant components: the web client, the tomcat application server and the web service provider.
Every user of the application has its own private client certificate (PKI Token, X.509- Auth-Cert). When the user connects to the web application his certificate is requested.
How can I forward the client certificates for use in the web services? (The tomcat will not be responsible for authentication).
1.) Is there a way to intercept the request and extract the client certificates before authentication error occurred?
I found some information about Servlet Filters what sounds really good, but I’m not sure where to implement it to intercept the certificates before they are verified against tomcats keystore.
2.) If it is possible, how can I pass after the client certificate to the web service?
Thank you for reading
No, not really. The real piece used in authentication is the private key associated with the certificate, not just the certificate itself. And, typically, you have no way of retrieving that from the web client. Therefore, you cannot really pass-through the credentials you receive from a web client on to the web service client. The certificate itself is readily available, but is useless for authentication without the corresponding private key.