I have an existing application and all of a sudden i have been given a task to implement IDP initiated SSO. there is a URL to IDP clicking on it asks me to login with IDP provided credentials, after success login the route moves to our application and than my task start to identify the user and give the proper access. I have the certificate provided from our IDP. How can i achieve this? My application is a Spring MVC Java Application.I am using JBOSS AS 7. I havent done a similar thing before. Can anyone please give a step by step clear picture on this? I saw the Spring SAML extension which i couldnt understand properly to get it integrate with my existing app. Any help in this regard will be highly appreciated.
IdP-Initiated SSO
IdP-Initiated SSO with POST Binding
If the user does not have a valid local security context at the IdP, at some point the user will be challenged to supply their credentials to the IdP site, idp.example.org.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The user selects a menu option or link on the IdP to request access to an SP web site, sp.example.com. This causes the IdP's Single Sign-On Service to be called.
The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML message. The message is then placed within an HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service. The service provider's Assertion Consumer Service obtains the message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource (not shown).
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.
See saml-tech-overview-2.0
So if you are implementing the SP, you have to follow the steps 5 and 6 otherwise 1 - 4.
For the implementation you could use OpenSaml if you do not get it working with the Spring SAML extension.
Related
I'm trying to develop a simple java client that needs to access Skype for Business APIs in order to setup an online meeting (i.e. I need to retrieve a simple setup meeting URL by invoking an UCWA API).
I followed this Microsoft tutorial step-by-step:
https://learn.microsoft.com/en-us/skype-sdk/ucwa/developingucwaapplicationsforsfbonline
I have an Office 365 Business Premium license and I configured a custom domain (correctly registered and added at the zone DNS file);
I configured and registered my java client app on Azure (taking care to assign required delegated permission for Skype for Business capabilities);
I performed the Sign-in phase and Azure is able to recognize me;
I performed the Autodiscovery phase in order to retrieve the user's UCWA home pool;
I sent a GET request to the Azure oauth2 endpoint with response 401 error (and this is the expected behaviour by the authentication handshake);
Unfortunately, I failed when I request an access token using implicit grant flow: Azure responds with a Sign-In HTML page rather than the json object containing the oauth2 access token.
What's wrong on this GET request?
GET https://login.microsoftonline.com/oauth2/authorize?
response_type=id_token
&client_id=my_application_client_id
&redirect_uri=configured_redirect_uri
&state=UUID_generated_code
&resource=UCWA_home_pool
HTTP/1.1
This GET URL looks like that one used for the Sign-In phase (step 3); I suspect that it isn't the right request URL.
I tryed to put my domain on the URL:
https://login.microsoftonline.com/my_domain_name/oauth2/authorize
and I tryed to put a common domain name (as reported on the documentation):
https://login.microsoftonline.com/common/oauth2/authorize
But Azure still reponds with a Sign-In page (and response code 200 OK).
Can someone help me please?
Please check the oauth2AllowImplicitFlow property in manifest of your application after downloading the latest manifest file. It should be set to true for this to wrok. If it's still false, only then I would expect the redirect to sign-in page as you're seeing.
More detailed steps here -
Configure your app for OAuth implicit grant flow
I have a web application that when user click on the a link it will generate security information and log on to an external application if the security information is authenticated.
At this point from security concern I don't want to expose the URL and request information on the web page, so instead I am seeking solutions to handle the process behind the scene
I know Apache Components can easily send post request within POJO, jersey client can do as well through web service. However the requirement here is also including to let browser automatically redirect to the 3rd app's front page if the login process succeeded.
My question is what could be the proper solution to handle the login process and go to the external application from web as well.
Say you have:
publicapp.com
secretapp.com
Set up an API in publicapp.com to POST the initial request to itself. When the user submits the initial login form it goes to say publicapp.com/login. This endpoint will pre-process the information then send a server to server request to secretapp.com/login.
If secretapp.com/login accepts the information it responds to publicapp.com with a success and publicapp.com redirects the client to secretapp.com/home, with a short term auth token encoded in a JWT. secretapp.com, swaps the short term token for a full auth token.
In the above scenario, the actual login endpoint is never made public. secretapp.com should also have IP whitelisting to only accepts login attempts from publicapp.com. You can also do a lot of filtering on publicapp.com to eliminate malicious requests without bothering secretapp.com.
We are implementing a soap client in Java (using cxf wsdl2java). In previous projects the authentication has been based on either WS-Security or Basic HTTP Authentication. These are both easy to test in SoapUI and implement in java.
This time however, the server uses a Web Application Proxy which works as a reverse proxy, and ADFS (Active Directory Federation Services) for authentication purpose. I don't know the details of what this means, but what happens when opening the wsdl endpoint URL in a browser is that we get redirected to a login page similar to the office login page https://login.microsoftonline.com/ where you have manually click on the account type before entering credentials.
When logging in manually, we get redirected back to the wsdl endpoint with an appended ?authToken=xxx at the end and I think the token lasts for 1 hour. We have tried to ask the provider to use a more standard authentication, but for now this is the only thing we have. How do we approach this?
When trying to do a test request from SoapUI, we just get the complete html code of the login page in response. I see there is a Form Based Authentication option in SoapUI but it won't work since the login page has multiple account types and multiple username/password fields. The workaround for testing is just to login manually and use the authToken. But how can we automate this in the Java cxf client?
When connecting to the endpoint url in a browser, this is how the url looks after redirected to the login page:
[url to adfs seriver]/adfs/ls?version=1.0&action=signin&realm=urn%3AAppProxy%3Acom&appRealm=a10037ed-ca1e-e711-9436-00215a9b01ac&returnUrl=[wsdl endpoint url]&client-request-id=13A5B5A6-B574-0000-6FBA-A51374B5D201
You can't use SOAP to authenticate with ADFS via a login screen. This is because ADFS only supports WS-Fed or SAML-P or OpenID Connect (ADFS 4.0).
What you can do is use WS-Tust to do this.
WS-Fed supports two profile viz. passive (browser login screen) or active (web service / WCF). You need to use the latter.
There are a number of active profile endpoints that are available in ADFS. Not all are enabled by default so you may need to enable them.
I have configured IdP and SP in my desktop.To test SSO, I have a single html page deployed in tomcat.I have given the url : http://machinename:portno(here tomcat's port)/webApp/index.html in default url of SP configuration. When I try to hit the SP SSO url,(http://machine_name:portno/sp/startSSO/ping) it redirects to IDP and prompts for authentication. Once the user is authenticated, the user is redirected to the tomcat webpage.
But, when I try to access the tomcat page, I am able to access it without any authentication. Is there any configuration on the SP side? If so, how to do it? When I access the web page, I should be prompted for authentication.
This configuration question really has nothing to do with PingFederate. This is more about how you have chosen to integrate your Tomcat application with the PingFederate SP Adapter. Chances are you are using the SP OpenToken or SP ReferenceID Adapter for a Java app in Tomcat- these Adapters merely provide the user's identity attributes to your application after the SAML Response is validated by PingFederate SP. It is up to your application to validate the specific token type (using the proper steps required by the SP Adapter you have chosen) and then your application is also responsible for enforcing access/maintaining a session based upon the user's identity that is passed in the token.
If you are expecting Access Control/Session management, I'd recommend looking at integrating PingFederate with PingAccess.
Bottom Line: Ping's solution's are hugely flexible so there are a number of ways to accomplish this based upon your application infrastructure and use case requirements. I suggest that you work with your Ping Identity RSA to help you work through these questions in order to have the best possible outcome.
I am facing an issue while using SAML to implement SSO on my web application.
After successful login I want to redirect to my application’s dashboard / main menu. But, it gets redirected to http://:/IDBUS/first-idau/IDP-1/SAML2/SSO/POST.
The flow is, I request my application’s context url in browser. In josso I have configured it to be redirected to atricore. Then there is a change in request headers and the request comes back to same application url I requested. Now I use a filter and redirect it to JOSSO login page. So this single request lands in JOSSO login page.
When I give credentials and login, then JOSSO authenticates and sets the user principal and sends the request to my url. Here I have a filter to forward to my dashboard.
In this step after I give authentication information in JOSSO login page, instead of getting my dashboard, it gets redirected to some JOSS page (http://:/IDBUS/first-idau/IDP-1/SAML2/SSO/POST) this is in OSGi bundle in Atricore.
When I debug, I see a HTTP header as “referer”. It pointing to the above URL. I think it should point to my application’s dashboard url which I have configured in josso-agent-config.xml
I did one analysis and found something interesting. In step 1, I have used a filter in my application to redirect to JOSSO login page. Instead of doing that, I allowed to complete the request. Then it gets landed in a page in my application.
Now in the same session (in browser), I manually made request to JOSSO login page. Then I got the JOSSO login page (this is step 2). Then I gave credentials and requested to login. Now it gets successfully forwarded to the intended my application’s dashboard page.
So my guess is that, there should be something wrong with my filter where I redirect to JOSSO login page.
I am using Atricore Identity Bus 1.0.0-m1+JOSSO 1.8.2+Spring 2.5.6.SEC01. Please help me on this.
First of all, I'd strongly suggest you to upgrade to Atricore M2 which was released last week and available here : http://sourceforge.net/projects/atricore/files/Atricore%20Identity%20Bus/Atricore%20Identity%20Bus%201.0.0%20M2/atricore-idbus-1.0.0-m2.zip/download . This release delivers tons of fixes and many significant enhancements such as native HA and scalability out-of-the-box support.
Also, make sure that you're using the final JOSSO 1.8.2 bits - not JOSSO 1.8.2 r1575 - released last week and available from the JOSSO web site (http://www.josso.org) .
Then, you should deploy the reference identity appliance for realizing a simple SAML-based Federated SSO setting encompassing a JOSSO Service Provider and a SAML2 Identity Provider. Make sure to follow the quick start :http://www.josso.org/confluence/display/IDBUS/Quick+Start
Going back to your original question, the URI your seeing is because JOSSO is relying on a SAML2 IdP Entity the authentication request (read: AuthNRequest) which, upon handled, returns the correpsonding SAML Response conveying authentication assertions.
The bottom line is that within a FSSO setting, the JOSSO Gateway concern is realized by an Identity Provider hosted in Atricore IDBus. Atricore Identity Bus is playing nice with JOSSO Agents (read: by speaking the "JOSSO" protocol) while bringing the standard-based FSSO capabilities on board, and without forcing you to invest in retrofitting your JOSSO Partner applications to SAML.
Hope this sheds some light on your issue and the subject in general.
Regards,
Gianluca.