How to authenticate with liferay by passing the parameters as user email and password. If authentication is success then I will redirect to different web web application.Actually i want to authenticate user without using sign in portlet.Is there any way we can hit a url and it gives a response text so we can identify that user is authenticated. i followed this link but i didn't get proper response.
Liferay integrates with a lot of different SSO (Single-Sign-On) systems on the market. Instead of reinventing the wheel, you should use one of those integrations. This way you're free to use whatever your SSO uses to authenticate the user and it will provide your user's identity to Liferay as well as to any other application.
For Liferay EE, you also have the option to make Liferay your "SSO" by utilizing the SAML plugin and creating Liferay into an IdP (Identity Provider) and by making your other application an SP (Service Provider).
The whole field of forwarding the identity of users has been solved and one shouldn't mock around with redirecting with any self-invented authentication scheme IMHO.
Related
I have two web applications app.domain1.com which is a SPA with his own API on api.domain1.com and app.domain2.com) with each have their own authentication system and user accounts
and I need to authenticate the user from app.domain1.com from app.domain2.com. The goal is to simplify switching from one app to another without requiring the user to log into each application by re-entering their password. I'm the owner of one app only so It's not possible to put them behind a reverse proxy or so.
Example :
app.domain2.com redirect to app.domain1.com/connect/{JWT} -> app.domain1.com SPA extract the JWT and send it via ajax to api.domain1.com for validation and login.
I have looking for OAuth2 and OpenID Connect for these but OAuth2 is more about delegation of resource access than authentication and OpenID Connect needs an Identity Provider which seems incompatible with my use case where each app has his own authentication mecanism and where I could not add a central authentication server.
Ideally, I'd like to adhere to a standard protocol.
I thought I could expose an endpoint GET /connect/{JWT} on each app.
The JWT could contains an email which could identify the user account, app.domain1.com and app.domain2.com could then share the secret for validating the JWT has not be tampered
and could have a short validity duration.
This endpoint validate the JWT, verify if a user match the email inside the JWT and log the user in.
I'm not sure about the security considerations with these process and if there is any other options ?
Thx for your help.
In my opinion you should go with OIDC. That protocol is designed exactly for the feature you described here. You can have one of the apps act as the IdP, and the other will be a Relying Party. It depends on which technology you use for your apps, but in some languages there are libraries which will turn your app into an IdP.
You can think of some generic protocol to make that federated login work, but you will be better off using standards. This way you won't have to wonder what are the security implications for your solution - you have security considerations for OIDC described in the spec itself.
I'm developing an Enterprise/Internet Application with WebAPI 2 RESTful server and SPA web client (Angular2) —So I have two separated projects created using ASP.NET 4.6 Empty template and both use OWIN and are IIS hosted.
The requirement for Authentication is:
Active Directory user which is logged in to the workstation will authenticated automatically once she opens any page from app in the browser if user id/name found in the database, with no need to enter her user/pass. Let name this as auto-login. Else if it's not found in the DB it will redirected to the login page.
Also there should be a logout option which redirects user to the login page after logging she out.
In the login page any AD user can enter her/his AD user&pass and after successful check against database (existed) and AD (valid credential) she/he will logged in to the system (Obviously it may be different than user currently is logged in to the workstation)
In addition to the web client it will have other clients such mobile apps which will connect and be served by the WebAPI back-end. Users will login there using their AD user & pass too. Let name it manual-login.
According to the REST architecture and having both AD enterprise and internet/mobile users together, the authentication should be token based —this is what I found till now but I'm not sure.
I read about OWIN Authentication architecture and Windows Authentication and I checked MixedAuth, Now I think it is the nearest solution for this requirement as it lets app-defined users to authenticate side by side of windows/AD users. But even after dig into it and its SPA sample I didn't found my way yet and confused.
Anyone can help?
What should I actually do on the WebApi server and SPA Client to accomplish those authentication requirements?
Which middlewares should I add and how should config/manipulate them?
UseCookieAuthentication ?
UseExternalSignInCookie ?
UseOAuthBearerTokens ?
Can I rely just on Bearer tokens (using OAuthBearerTokens MW) and get same token for authenticated windows users to unify authentication model based on bearer tokens? If so, how?
How and where should I put my code for checking that AD user exists in the DB and if not so reject the authentication?
Thanks a lot.
We have an existing MVC application which is used by multiple customers.
Currently, each customer is given a URL to our application e.g. https://myapp/mycustomername.
When they go their, they are presented with a login screen.
For some customers (not all) we want to implement SSO, and authenticate their users against their active directory, so that they never see the login screen (unless the SSO authentication fails).
Most customers won't be using this functionality.
My first question is: is this do-able? Is it possible to have an MVC application which uses both SSO and forms authentication?
If so, can anyone point me to any links explaining the process?
I've seen some good information, such as this tutorial but I can't find anything that matches my scenario.
Thanks.
This is surely a do-able task.
The steps would be
Identify the tenant name from the URL
Get the Identity Setting
If forms authentication, show them the login page
If SSO enabled, redirect to their ADFS URL
When you onboard your tenant, you will have to maintain the following metadata
TenantName
AuthenticationType : {forms / ADFS}
SSO Url
SSO Federation Metadata URL
etc
We did one such implementation that supports ADFS, Social Logins with Forms Authentication too.
Good evening, I must make an intranet with Liferay, the most important is to integrate a web application (or 2) already ready with the portal that I will make . These web applications are made in php, so in order not to make each authentication, wanted the user to authenticate to the portal and click on the link to one of these web applications, it will not have to authenticate again for its apps. For this reason I used SSO CAS and I integrated it with Liferay, I still used an LDAP directory to be related to the CAS server to identify users.
My problem is how is the procedure for other web apps, is that users must have the same login and password for partail (Liferay) with the others two apps php? Or I can let each application with their users without the change (because in each app, the user has a login and password different from other apps), that is how the coordination between different words and LGIN passes the various apps (this is a problem of SSO, I misunderstood the principle of work I should implement it) ??
Some clarifications and assistance please??
The other webapps need to implement a so called CAS Client. The php one is here:
The php apps will typically redirect non authenticated users to CAS, and after they logged in the webapp retreive a saml token. In that token claims are found that uniquely identify the user. application then typically match the provided claim to their own userstore or apply the concept of a virtual user.
But that is up to the implementer of the webapps.
OpenID authentication is inherently browser based. If I wanted to allow an OpenID user to authenticate against an API for use in alternative clients, is there an accepted best practice for that?
So if a user tried to log in with their OpenID into an iPhone app, for instance, how would that work? The only thing I can think of generating an API token of some sort for them and get the user to manually enter it somewhere. This approach is not user friendly.
This is the way sites like Basecamp work, but it still seems clunky to me.
The problem you're seeing is not unique to OpenID. Any password-less authentication scheme can have this problem. OAuth (http://oauth.net/) is a solution that is an open standard that is quickly gaining traction on a lot of web sites. It is totally independent of how the user authenticates, so their OpenID Provider does not need to support or even be aware that your site (the "service provider" in OAuth terms) is using OAuth. Your API client can be web based or even a local application!
The process would be something like this:
Roles:
the user: someone who has an account with your web site.
service provider: your web site, which has a programmatic API that requires some credential to access.
consumer: the client, whether web or local application, that needs access to the service provider's API.
Flow:
The user is at the consumer. He indicates he wants to access data at the service provider.
The user is either redirected (if the consumer is a web site) or a browser is popped up (if the consumer is a local app) and the user sees the service provider web site.
The user is either already logged into the Service Provider via a persistent cookie, or the user must first log into the Service Provider however that is done (OpenID in your case).
The Service Provider then asks the user: "Consumer (some consumer) wants access to your data (or our API, or whatever). Do you want to authorize this? (yes/no)
User confirms, and the browser window closes or is redirected back to the Consumer site.
Via some OAuth protocol magic, the consumer now has a secret credential that it can use to access your API and access whatever user-private information you just authorized.
Obviously I can't include the whole OAuth spec here, but you can see hopefully from the above that this should solve your problem. OAuth libraries exist to make adding support for it easy.
If you happen to be using ASP.NET, I suggest http://dotnetopenid.googlecode.com/ as it recently added OAuth support (v3.0 beta 1).
Neither OpenID nor OAuth define how a user authenticates. They define how the consumer directs the user agent to the authentication provider, how the user agent is directed back, and how the consumer can verify the identity that the user authenticated as.
The actual method used to authenticate is out of band for both schemes.
There are differences between OpenID and OAuth, but both require that the consumer use HTTP redirects and callback URLs. They're both browser based. If your app speaks HTTP, it can do either. However, a main point is that the user is only entering credentials into a trusted app.
What you want is not possible with OpenID. OpenID is based on the premise that you (the iPhone app) only want to know about your users that their OpenID-provider trusts them. They never authenticate themselves to you.
Good OpenID-providers in fact even prevent that you mediate the authentication process (as this would expose users to a possible attack - by you!): they demand that users login with them directly and refuse login-by-referral.
See: this related question
The problem is that the openid spec has no standard provision for authentication with the provider, so the provider can elect that authentication happens via a phone call or whatever.
Hopefully more providers embrace OAuth. Alternatively you could hand code the authentication for a few of the bigger sites.