I'm following the Java EE 6 tutorial and I'm reading the part related to security.
In the examples, the user management is done using the features provided with the Glassfish server. Is this the usual method used to manage users in Java EE?
Is it possible to use mechanisms such as e-mail based user account creation (password sent via email) etc. by using this method? If not, what alternative mechanism/library do you recommend for user account management?
I found the answer to my problem here.
Related
I want login system in my capsule so that i can provide user more recommendation based on their profile of interest. So far, neither I am able to find any document related to login facility nor any example. It would be appreciated if will get any document or example.
Bixby supports logging in through OAuth 2.0, and this is the best way to guide your users through a login flow.
You will need to provide your own service to handle this OAuth flow, as Bixby Developer Center does not offer any web hosting services.
https://bixbydevelopers.com/dev/docs/dev-guide/developers/actions.using-oauth
Also is there a possibility that user can user can use app as a guest
user if no login credentials?
When you define your endpoints, you can define Actions that require OAuth and other Actions that do not require OAuth and the latter ones will define the "guest user" flow that is capable within your capsule prior to logging in.
If you don't need all the features of OAuth, and only need to store a few things between sessions with the same user, you may use the $vivContext.bixbyUserId value as an anonymous, but unique identifier for a user, and store their preferences using that id as a key, in a 3rd party database that you maintain.
I've done this with the "My Brain" capsule, to store quick memories/notes for users, without any requirement that they login or establish an account. I've created a tutorial version of the My Brain capsule that outlines the steps you need to use AWS for this purpose. Please feel free to clone or fork it and customize it for your needs.
What Cross-Domain Single Sign-On implementation best solves my problem?
I have two domains (xy.com & yz.com) which already have their own database of users and are already implementing their user authentications separately. Recently there has been the need to implement CDSSO so that users dont have to log in each time they try to access resources from both domains.
Ideally the CDSSO implementation I hope to use should allow custom implementation of authentication, as I hope to call API's provided by both domains during authentication to confirm a user exists in at least one of the domains user database.
I've been looking at Sun's OpenSSO which seems to provide a means to extend its AMLoginModule class yet this seems to be a long thing and more annoyingly they seem to stick to GlassFish.
I've also considered developing a custom CDSSO to solve our needs. Is this advisable?
Is this achievable using Suns OpenSSO considering the disparate user database as I there will be no need to make use of the User db that OpenSSO requires?
Are there any simpler means of achieving what I intend to achieve?
In addition both applications which exist on the two domains were developed using PHP. How does this have an effect considering Suns OpenSSO is based on Java EE?
Are there any clearly specified steps on implementing OpenSSO and or any other SSO implementations from start to finish?
I suggest you to use simpleSAMLphp in order to deploy an Identity Provider and 2 Service Provider (for each app).
SimpleSAMLphp allows you to select multiple authentication source and is not hard to build your own authsource that consults the 2 databases.
My experience in SAML says that the fact of not consolidating the Identity of the user in 1 unique authsource is a bad idea due several reasons:
* identity conflicts: what happen if you have the same user registered with different mail (if that is the field yoy use to identify the user) and you try to access? You could be logged in different account each time.
* what happen if you add a 3rd service, do you gonna add a 3rd database
* what happen if user change its data in one app, the other gonna be no synched?
* what happen if user uses different passwords?
I recommend you to execute a migration process before adding the SAML support and build a unique database for all your identities and unify the registration/edit profile/password recovery process of both sites in one.
SimpleSAMLphp has good documentation, but I can provide to you any documentation related to the process that I suggested.
We need to show document from alfresco in Liferay portlets. We would use the CMIS connector with the document library. But we are required that the users be authenticated with OpenAM (a sso).
All the research I've done seam to indicate that ootb it doesn't work. But I can't find anyone that made it works.
So is it possible to use the CMIS connector with an SSO authenticated user?
If yes, what step should we do, or is there some doc already available?
If no, Is there any work around or other solution to connect Liferay with alfresco with an SSO authenticated user?
So to summarize the situation, no, by default there is no way to use Liferay document librairy/cmis connector with any SSO.
But, it is possible to use it by modifying the Liferay feature (With hook) and using a specific strategies (This go from proxy sso to some java script hack that I wont go to deep into as we decides not to do it) to get the required info to send to alfresco.
Other solution (that we chooses) is to implement a custom authentication on alfresco and to use a password that is not the user one as password, but there is some security concern that need to be taken into account with this solution because the simple way to do it create a "master password" that could be used by anyone.
So basically there is really no one size fit all solutions on this subject.
What are the basic functionality which it provides?
Specifically for the person who has never used asp.net built in stuff.
The MSDN tutorial is confusing me a lot. Claims, OWIN,etc are going above my head.
What I can make out of all this is - The Identity framework helps me to manage my application plus social logins. It handles my cookie,etc.
What if I have just one role in my application - just the plain user?
Should I go for the Identity then or I should implement my own custom thing?
Any help is appreciated.
If you are starting from scratch, build a sample MVC project with individual membership option, which will create the following components for you:
Login module that creates and manages authentication cookies
Simple database to store basic user data (credentials, name)
EF code to interact with the database
This will most likely meet your use case for a user without roles and attributes.
OWIN really has nothing to do with authentication, it is a new spec for building web apps. The login module happens to be implemented according to this spec and it sounds cool, so Microsoft likes to throw this term around a lot.
If you are not planning to have authorization logic in the app, then you don't need to worry about Claims. Claims is another term for user attributes (login, name, roles, permissions). The Claims collection will be populated by the framework, but you most likely won't use it. If you need just the user id/name, the old ASP.NET interfaces are still there to get this data.
As far as implementing your own, I've seen people here ditching the database and EF code, especially if they already have an existing user store. You just need to implement a credential verification logic against your store. You don't want to build your own cookie management, though. Use the login module provided by Microsoft or well established third party systems (SiteMinder, Tivoli, etc.)
Looks at this open source project for a good alternative to ASP.NET Identity.
This is a very well put together tutorial that explains many of these concepts, you can get a free trial to the site to see it.
I need to quickly customize the user registration form of the liferay/web space portal? Have not found any direct information on this so would appreciate any tips.
There are several possibilities:
The source is available, so you might want to patch the existing process
The API is available (e.g. see this thread in the liferay forum), so you can batch-create users or implement your own registration portlet and just use the API. AFAIK you can even register users via a webservice interface.
You can batch-insert users into the database
If your existing user data is stored in LDAP, you can connect Liferay to the database.