Landing page
by Gabriel Cardoso
Regarding the issue https://issues.jboss.org/browse/KEYCLOAK-3, I was thinking about the scenarios. Maybe creating a realm is an unnecessary step from the user's perspective. I can imagine cases where the administrator will just want to manage one application. However, creating a realm may be useful in case of more than one application, if I understand properly. See the scenarios:
#1: Jared is accessing the application for the first time. He wants to set up the login for an application he is working on.
After logging in, Jared sees the "Overview" page that shows he has not set up any applications yet. Jared click the button "Set up a new application". On that page, Jared set up things like the application name, the user permissions and the social login. As an advanced option, he sees that if he wants to use the same information for more applications, he can create a realm. Since he just want to deal with one app right now, he skips this option.
#2: Jared wants to manage multiple applications.
Jared has already set up an application and wants to manage another one with Keycloak. Since this second application is related to the same group of users as the first, he wants to create a realm. After logging in, he sees the "Overview" page, with a list of applications, and the options to "Set up a new application" and "Create a realm". Jared clicks this button and, in the realm creation page, selects the option to fill in the fields with the application data he has already set up. Jared fills the other fields and create the realm. He is redirected to the "Overview" page that now shows his applications and realms. He clicks "Set up a new application" and associates it with the realm that he has previously created. Jared finish filling the form and the set up is done.
Does this make sense?
Gabriel
12 years, 10 months
Re: [keycloak-dev] configuring social providers
by Bill Burke
On 7/22/2013 8:56 AM, Stian Thorgersen wrote:
> I'm confused, I'll try to step through the process of a user that logs in via Google through Keycloak, to check that we have the same understanding:
>
> 1. A user visits www.acme.com and clicks on login (see attachment p01.jpg)
> 2. The user clicks on the Google icon as the user can't be asked to register with yet another site
> 3. The user is redirected to Google to allow Acme to access basic details about his account (see attachment p02.jpg)
> 4. The user is redirected back to the Keycloak callback, which retrieves the user profile from Google, creates an internal user in Keycloak, and eventually redirects the user back to www.acme.com/logged-in
>
> Next time the user visits www.acme.com (and is not still logged-in) the user can click the login with Google icon again and is redirected to www.acme.com/logged-in without having to grant permission to the application, or login to Google (as long as the user is already logged in with Google).
>
> Finally, the user can now choose to disable access for the application to his Google account (see attachment p03.jpg). If the application is revoked, the user expects to next time he tries to login with Google to have to re-authorize access for Acme to his Google account.
>
> The key things to note is that a user grants access to his Google account, which he does to Acme (the application), not to the Keycloak server. Initially I would say it's best to have a config per application, then later introduce a mechanism to share these between multiple applications when that makes sense. However, for an online version of Keycloak (public SaaS) it would never make sense to have a global configuration.
>
Ridiculous...Of course it makes sense to have a global account for the
SaaS...Its a lot easier to set up if there is a global Keycloak account
that is re-used. Simple is "Enable Social Login" checkbox. Advanced is
setup your own account.
BTW, how many web surfers even know that the revoke feature even exists?
keycloak.org - [REVOKE]
makes about as much sense to me as a few of the domains I have listed in
my own revoke page:
si.auth.fyre.co
While fyre.co is an identity broker, I don't know WTF "si" is.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 10 months
IRC channel
by Stian Thorgersen
Would be good to have an IRC channel that we can hangout on, maybe #keycloak on Freenode?
12 years, 10 months
Re: [keycloak-dev] CORS
by Stian Thorgersen
It's useful to the JavaScript SDK so that it can do REST calls to the server. This could be used to for example:
* Get login configuration, for example what social providers are enabled for a site. This can be used to create custom login forms that are well integrated into the site
* Get user profile
* Logout user
It should be an optional value and only needed if the JavaScript SDK is used. It's also a feature that we wouldn't certainly need for the first milestone
----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com>
> To: "Bill Burke" <bburke(a)redhat.com>
> Sent: Monday, 22 July, 2013 9:27:58 AM
> Subject: Re: [keycloak-dev] CORS
>
> It's useful to the JavaScript SDK so that it can do REST calls to the server.
> This could be used to for example:
>
> * Get login configuration, for example what social providers are enabled for
> a site. This can be used to create custom login forms that are well
> integrated into the site
> * Get user profile
> * Logout user
>
> It should be an optional value and only needed if the JavaScript SDK is used.
> It's also a feature that we wouldn't certainly need for the first milestone
>
> ----- Original Message -----
> > From: "Bill Burke" <bburke(a)redhat.com>
> > To: keycloak-dev(a)lists.jboss.org
> > Sent: Friday, 19 July, 2013 6:40:15 PM
> > Subject: [keycloak-dev] CORS
> >
> >
> >
> > On 7/19/2013 9:59 AM, Stian Thorgersen wrote:
> > >
> > > The authorized javascript origin is used to specify what domains are
> > > allowed to do CORS request. This is required by the JavaScript SDK so
> > > that
> > > it can invoke REST endpoints when deployed to a different domain than the
> > > IdentityBroker server.
> > >
> >
> > Does Keycloak need CORS? OAuth2 is a redirect protocol.
> >
> > 1. user visits app
> > 2. App redirects to keycloak login screen, sets a session cookie for
> > security purposes
> > 3. Userlogins into Keycloak
> > 4. Keycloak sets a cookie and generates an access code
> > 5. Keycloak redirects browser back to app
> > 5.1 App checks to make sure it actually made an access code request by
> > lookat at the session cookie in step 1.
> > 6. App extracts access code from redirect URL
> > 7. App makes an under-the-covers invocation to change the short-lived
> > access code to a token
> > 8. App extracts identity and role-mapping information from token.
> > 9. User visits a different site
> > 10. Site redirects to keycloak login screen
> > 11. Login screen sees that the user is already logged in (via cookie)
> > 12. Keycloak generates an access code and redirects to 2nd app
> > 13. App extracts access code from redirect URL
> > .....
> >
> >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
12 years, 10 months
demo available soon
by Bill Burke
I'll have an end-to-end application demo soon. It will be crappy, but
at least some aspects will work. A shitty auth-server, managing a
jboss-eap web app, jboss-eap oauth client, jboss-eap rest service.
Basically the same demo I had for Resteasy Skeleton Key, but with the
bare bones crappiness of Keycloak as the auth server.
After that, I'd like to start merging keycloak and identity broker.
- login
- social login
- oauth login
At least get those 3 aspects going with your UI framework and social
provider plugin architecture.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 11 months
Home page
by Gabriel Cardoso
Hi people,
Today I did an exercise about what information we should display at the Keycloak homepage. The result is the wireframe below, that has the following goals:
- Present the concept of Keycloak for a new user
- Create engagement by showing how easy and flexible it is
- Be clean: straightforward information
- Provide links for login / registration (try it now)
Considerations:
- The slogan is not supposed to be definitive, but it is interesting to have one.
- The images would be vectorial, representing concepts, instead of photos.
- Learn more of each topic is an anchor for the extended explanation below them.
- The extended explanation must have as much text as it requires, but less is better. Also, se can work on interesting diagrams.
- Try it now (register) is presented in different regions of the page since is our primary action
The idea is to have something upon which we can discuss. What do you think about it?
Gabriel
12 years, 11 months
Redirect URI and JavaScript origins
by Stian Thorgersen
In IdentityBoker you can specify a single redirect url and a single authorized javascript origin. The plan was to eventually allow multiple of both, including the use of patterns. So for example for a single application the following values would be valid for redirect uri:
http://hostname/site/welcome.html
http://hostname/site/*.html
http://hostname/site/*
An redirect_uri query parameter is used to specify the actual value, and it is required to match one of the values specified for the application. It should also be possible to select a default redirect uri that is used if no redirect_uri parameter is included.
The authorized javascript origin is used to specify what domains are allowed to do CORS request. This is required by the JavaScript SDK so that it can invoke REST endpoints when deployed to a different domain than the IdentityBroker server.
This is pretty much the same as Google does with the addition of being able to specify patterns in the redirect_uris. The main purpose of adding this is so that users can be redirected back to the page a user was on prior to clicking on login.
Does this match the plan for Keycloak?
12 years, 11 months
Keycloak UX design
by Gabriel Cardoso
Hi Bill,
Today I had a meeting with some designers of JBoss and they suggested me to take a step back and try to understand the structure of Keycloak and goals of the people who will use it before diving into the graphic design. Based on this, I generated some materials that I would like to validate with you:
Project definition
Keycloak is a central login service for one or more web applications and web services. It also is a central place to manage what a logged in user is allowed to do and what permissions the user has. It is a cloud service that allows administrators to secure their web applications.
Personas [1]
Jared Rubin [2]
Jared is an administrator of IT systems with bachelor in technical degree. He usually works on more than one project and his goal is to ensure that SSO, security, and other common services are working properly with his systems. He works to upgrade systems and make configuration changes, as well in application deployments. He often uses the command line, more than GUI.
Linda Johnson [3]
Linda is a regular user of the internet. She access various portals and services and eventually sign up to new services that she finds interesting. Although she is familiar with the process of creating new accounts and logging in, she does not understand technical terms and is often in trouble when she needs to set up something on her computer. She is familiar with intranets and services like Facebook and Google.
Scenarios [4]
The company where Jared works on is creating a new web application. They asked Jared to take care of the login part of the app. One of the requirements is to allow social login via Facebook, Twitter and Google. Jared hear good things about Keycloak and decided that this is a good opportunity to try the service. He access the Keycloak homepage and easily understands what the solution does and the benefits of using it. As he is interested, he jumps to the documentation to see how he can implement it on his new app. After reading some documents, Jared goes to the registration page and create an account. After that, he access the login page and log in the SaaS. He creates a realm and some users to test the service. He also creates an application and sets up which users have access to some restricted areas of the app. He finds the configuration process very easy and access his application to test it.
Linda heard about an interesting app to mage her to dos. She access the app, reads about it and click Sign in. She sees that she can login via Facebook and clicks the button. She allows the service to use Facebook login but does not want to share this information on her profile. After two clicks she is signed in the application.
Site Map
Based on the tasks you listed in JIRA and on the scenarios above, I created a site map with the structure of the pages. I added a homepage for the SaaS, which I think we can put some information about the project, as the scenario describes. A good benchmark for this is the Open Shift homepage.
Sorry for the long email but I needed to check if my understanding of the project is right. So here are some points that I would like to validate with you:
1) Do you think Jared and Linda are appropriate to represent the public that we want to use the service? What can be changed?
2) Do you think the scenarios represent the goals that people will try to achieve in the context of this first release? Improvements?
3) What do you think about a homepage to introduce the users to the service?
4) Is that site map correct?
Thanks,
Gabriel
-----------------
[1] Personas represent a group of users who we expect to use the product. We give him a name and some characteristics to create empathy among team members and think of him as a real person.
[2] This short description was based on one of the personas developed for JBoss, Jared Rubin. The whole set of JBoss personas can be seen here: https://community.jboss.org/wiki/JBossPersonas
[3] I tried to come up with this one to represent the users of the realm login.
[4] Scenarios are narratives that describe a persona interacting with the system from the user's point of view.
12 years, 11 months
Pulling in reusable stuff from Identity Broker
by Stian Thorgersen
I've started to pull in reusable stuff from Identity Broker, and at the same time done some refactoring. It's here:
https://github.com/stianst/keycloak/tree/idb-pull
It's a work in progress at the moment, but the general idea is to pull things into 3 components (all jars):
* sdk-html - sdk for html and js applications, this includes the login and registration forms
* social - social spi + google and twitter implementations
* ui - web app to create/manage applications/realms/users
12 years, 11 months