How can I remove login page of jasperserver-pro webapp. I want to embedd jasperserver dashboard as an iframe into external dashboard (outside jasperserver)
There are 2 options:
you allow anonymous access to the dashboard
you setup some form of authentication:
passing j_username and j_password as URL parameter
using single sign on like cas or siteminder
creating a custom authentication.
There is an authentication cookbook for JasperReports server available that describes single sign on with cas, the ultimate guide provides details on custom authentication (see documentation), in the jaspersoft community wiki you will find more examples, e.g. for siteminder.
Related
I have a requirement that needs to have login page at the service provider and I use java web app. Is there any way to use the spring SAML libraries to achieve this behaviour ? If so, what could be the steps? (it seems the default behavior of spring library is to redirect to IDP login page and I am not sure if we can configure to host login page on the service provider and relay that request to IDP)
I think what you're looking for is having two different ways to authenticate, one locally and one through SAML. I believe for having a login form, you would want to separate configurations with different AuthenticationEntryPoints, i.e. go to /login for local or /saml/login/alias/" + spAlias+ "?idp=" + spEntityID for direct login to SAML.
It sounds like right now you have SAML protecting any URL, which by default redirects you to the IDP since it's configured. The first step that I would take is getting user name and password authentication working with logins independently of SAML, then add SAML back in. Be sure to list whatever URL the login form uses as permit all so SAML doesn't kick in.
I am building a Spring-MVC-Hibernate back-end with dozens of RESTful web-services. The front-end will probably be an HTML5, CSS3, and JQuery web-app that utilizes back-end web-services I am developing.
We have an OpenAM 10.x SSO system on a Tomcat server, and we want to us that for authentication, no authorization rules are here or groups. All the documentation I have seen has been with an unknown version of OpenAM and Spring Security 3. We have OpenAM 10.x with no known time to upgrade to the latest OpenAM. We plan on using Spring Security 4.0.3, which is the latest at this time.
1) One way we can do this is to establish a Circle Of Trust, and then establish an IDP and a SP, and then we'll have a URL in order to do Federated SSO. I believe this is how our front-end will get authentication and get a token returned to the front-end and may be stored as a cookie.
2) Another way I have seen this done is to simply call the OpenAM restful api, pass in username and password and get a token. That token will then be used to pass into the back-end RESTful api's for security.
We will definitely be using Spring Security for Users, Roles, and Permissions (authorization), so can we do this? Use Spring Security 4.0.3 for users, roles, and permissions, but use OpenAM for authentication???
Any information would be very helpful. Thanks!
We've been doing something similar with one of our applications. We started by using OpenAM 12 and we're now using OpenAM 13 SNAPSHOT.
We've been integrating using OpenID Connect though, not SAML.
This was a good starting point for us: https://github.com/fromi/spring-google-openidconnect.
We used the default header/basic scheme in OAuth2ProtectedResourceDetails as opposed to form as in the sample.
On OpenAM, you'll have to configure OpenID Connect Provider.
Steps in OpenAM 13:
Login as amAdmin.
Select the realm.
The landing page (Dashboard/Realm Overview) will list common tasks.
Choose Configure 'OAuth Provider', then 'Configure OpenID Connect'.
Choose default values and click create.
Then you'll have to add an agent/client.
Steps in OpenAM 13:
From within the realm configuration page, choose agents.
Select OAuth 2.0/OpenID Connect Client.
Click on new button, enter client_id and client_secret values and create the agent.
Click on the newly created agent to further configure parameters such as redirect_uri, scopes etc.
If you cannot chose OpenAM 12 or 13 and are stuck with OpenAM 10, this information may not be useful.
I am doing a POC where I need to integrate the Shibboleth SP with OKTA idp provider.I have completed all below steps documented on OKTA official site for this integration.
Install Shibboleth Service Provider
2.Configure the webserver to use Shibboleth
3.Configure Shibboleth to protect a specific folder Create an Okta SAML 2.0 Template application
4.Modify Shibboleth to use the metadata obtained from the Okta application 5.Modify the attribute-map.xml file within Shibboleth
to set the appropriate header variables
6.Restart everything
But there are details missing from the step 5 where I need to modify the atrribute-map.xml. when I fire my protected URI(hosted on apache) it is getting redirected to OKTA login page. But after user enters the user-id and password and clicks login I get a spinner on my browser and it never takes me to my protected site URI hosted on Apache. Any clues to fix this attribute-mapping in Shibboleth SP is highly appreciated.
If the page is not being redirected to SP, he problem need not be with attributes-map.xml
Endpoints could be incorrectly configured. Check
{web app uri}/Shibboleth.sso/Metadata to see if the endpoint URLs are correctly defined.
Check Shibboleth2.xml if entityID is correctly defined, this is the web application that Shibboleth is protecting.
Check {web app uri}/Shibboleth.sso/Session this displays if all the attributes that are being sent from Okta. You can make it display the values too by changing Shibboleth2.xml since it is just POC.
Finally comes attributes-map.xml where you can configure attributes as agreed with Okta. There are some default attributes like NameID that are pre-configured here. You can see the format in attribute-map.xml and in /Shibboleth.sso/Session and code to make use accordingly. For example
formatter="$NameQualifier!$SPNameQualifier!$Name"
If you are adding custom attributes a simple element as shown below should work as long as the name is matching the attribute name that Okta is sending.
This issue was resolved by doing proper configuration on the OKTA side .OKTA provides sam2.0 template app for integration with shibboleth .The below mentioned parameters of this template app were properly configured.
Post Back URL -
Name ID Format - Transient
Recipient -
Audience Restriction -
authnContextClassRef - PasswordProtectedTransport
Response - Signed
Assertion - Signed
Request - Compressed
Destination -
Attribute Statements - username|${user.userName}
Then our integration was succesful
I've a web application which is configured to use SSO - Siteminder authentication. Now we have developed over own custom authentication code and want it to be implemented instead of using Siteminder. The application is being deployed in WAS 8.0 server which by default is using Siteminder. So even after we changed our code to perform custom authentication I don't know how when deploying it to server it automatically redirects us to SSO login instead of our custom login page.
In my local machine, the same code picks up this newly developed custom authentication and we've tested it too successfully. But when this code is deployed in actual DEV server, it ignores our custom login module and goes to Siteminder login page. Do I have to set something at the server side to disable SSO ? If so, can anyone tell me how to disable Siteminder at server for my application?
You need to disable the TAI (Trust Association Interceptor) for Siteminder. You can either disable TAI completely or just the Siteminder Interceptor. Via Admin Console go to Security>Global Security>Web and SIP Security>Trust Association to make the necessary changes.
HTH
Dan
I have a website with some areas that require a login via forms-based authentication, using my own provider that connects to the database.
The website is in preview so I want to protect the entire site via basic auth to prevent unauthorized access before it goes live.
The problem is when basic and forms auth is on the pages that will be public go to the forms login instead.
How can I keep the forms based authentication for member login and portal access, but protect the entire site from public access before go-live by using basic auth?
I think you should be able to satisfy your use case in the following manner.
Within the site .Net Authorization Rules create a Deny rule for anonymous users.
At the site Authentication enable Basic and Forms authentication. Disable all other authentication types. This should require all users to be authenticated with basic authentication to use the base site and then require forms login to the parts of the site that requires your custom authentication.