Hi guys,
Since you want to push Fedocal and Blocker tracking into production, would you mind to change you login forms, that I don't have to enter my FAS password into your application dialog boxes? Although I understand that they are Fedora's application, hosted on Fedora's infrastructure, etc. , I don't feel comfortable to enter my FAS password into various applications, which I consider 3rd party from this perspective.
Thank you.
Vít
On Thu, 2013-04-25 at 10:07 +0200, Vít Ondruch wrote:
Hi guys,
Since you want to push Fedocal and Blocker tracking into production, would you mind to change you login forms, that I don't have to enter my FAS password into your application dialog boxes? Although I understand that they are Fedora's application, hosted on Fedora's infrastructure, etc. , I don't feel comfortable to enter my FAS password into various applications, which I consider 3rd party from this perspective.
Do you consider the wiki, pkgdb, bodhi as 3rd party apps?
Pierre
Dne 25.4.2013 10:09, Pierre-Yves Chibon napsal(a):
On Thu, 2013-04-25 at 10:07 +0200, Vít Ondruch wrote:
Hi guys,
Since you want to push Fedocal and Blocker tracking into production, would you mind to change you login forms, that I don't have to enter my FAS password into your application dialog boxes? Although I understand that they are Fedora's application, hosted on Fedora's infrastructure, etc. , I don't feel comfortable to enter my FAS password into various applications, which I consider 3rd party from this perspective.
Do you consider the wiki, pkgdb, bodhi as 3rd party apps?
Pierre
Well, you are right, they should be adjusted as well. Copr is doing it better.
Vít
On Thu, 2013-04-25 at 10:31 +0200, Vít Ondruch wrote:
Dne 25.4.2013 10:09, Pierre-Yves Chibon napsal(a):
On Thu, 2013-04-25 at 10:07 +0200, Vít Ondruch wrote:
Hi guys,
Since you want to push Fedocal and Blocker tracking into production, would you mind to change you login forms, that I don't have to enter my FAS password into your application dialog boxes? Although I understand that they are Fedora's application, hosted on Fedora's infrastructure, etc. , I don't feel comfortable to enter my FAS password into various applications, which I consider 3rd party from this perspective.
Do you consider the wiki, pkgdb, bodhi as 3rd party apps?
Well, you are right, they should be adjusted as well. Copr is doing it better.
So you are in fact speaking about porting our apps to use OpenID, which is indeed something we are working on. But, don't you consider OpenID as a 3rd party application as well ? :)
Pierre
Dne 25.4.2013 10:57, Pierre-Yves Chibon napsal(a):
On Thu, 2013-04-25 at 10:31 +0200, Vít Ondruch wrote:
Dne 25.4.2013 10:09, Pierre-Yves Chibon napsal(a):
On Thu, 2013-04-25 at 10:07 +0200, Vít Ondruch wrote:
Hi guys,
Since you want to push Fedocal and Blocker tracking into production, would you mind to change you login forms, that I don't have to enter my FAS password into your application dialog boxes? Although I understand that they are Fedora's application, hosted on Fedora's infrastructure, etc. , I don't feel comfortable to enter my FAS password into various applications, which I consider 3rd party from this perspective.
Do you consider the wiki, pkgdb, bodhi as 3rd party apps?
Well, you are right, they should be adjusted as well. Copr is doing it better.
So you are in fact speaking about porting our apps to use OpenID, which is indeed something we are working on.
Thats good, thanks.
But, don't you consider OpenID as a 3rd party application as well ? :)
It is at least one single place to trust.
Vít
On Thu, 25 Apr 2013 10:57:54 +0200 Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Thu, 2013-04-25 at 10:31 +0200, Vít Ondruch wrote:
Dne 25.4.2013 10:09, Pierre-Yves Chibon napsal(a):
On Thu, 2013-04-25 at 10:07 +0200, Vít Ondruch wrote:
Hi guys,
Since you want to push Fedocal and Blocker tracking into production, would you mind to change you login forms, that I don't have to enter my FAS password into your application dialog boxes? Although I understand that they are Fedora's application, hosted on Fedora's infrastructure, etc. , I don't feel comfortable to enter my FAS password into various applications, which I consider 3rd party from this perspective.
Do you consider the wiki, pkgdb, bodhi as 3rd party apps?
Well, you are right, they should be adjusted as well. Copr is doing it better.
So you are in fact speaking about porting our apps to use OpenID, which is indeed something we are working on. But, don't you consider OpenID as a 3rd party application as well ? :)
Well I think the idea is simple enough - if there is one, branded and obvious login page - and that page is openid then we're not training our users to type their passwords into random websites.
-sv
On Thu, 25 Apr 2013 09:11:00 -0400 seth vidal skvidal@fedoraproject.org wrote:
Well I think the idea is simple enough - if there is one, branded and obvious login page - and that page is openid then we're not training our users to type their passwords into random websites.
Right. I think this is definitely where we are headed, but we aren't there yet. ;(
So, yes, I think we need to add support to fedocal and blockerbugs for openid, but not sure it's a blocker for them moving to production now.
Moving forward, we might consider making it a blocker, especially once we have other things moved over to openid already, but I don't want to change the goal posts for existing apps in the middle of the process.
kevin
On Thu, Apr 25, 2013 at 12:31:54 -0600, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 25 Apr 2013 09:11:00 -0400 seth vidal skvidal@fedoraproject.org wrote:
Well I think the idea is simple enough - if there is one, branded and obvious login page - and that page is openid then we're not training our users to type their passwords into random websites.
Right. I think this is definitely where we are headed, but we aren't there yet. ;(
SAML is another way to handle logins to web based services without the services getting access to the credentials.
Dne 25.4.2013 20:31, Kevin Fenzi napsal(a):
On Thu, 25 Apr 2013 09:11:00 -0400 seth vidal skvidal@fedoraproject.org wrote:
Well I think the idea is simple enough - if there is one, branded and obvious login page - and that page is openid then we're not training our users to type their passwords into random websites.
Right. I think this is definitely where we are headed, but we aren't there yet. ;(
So, yes, I think we need to add support to fedocal and blockerbugs for openid, but not sure it's a blocker for them moving to production now.
Neither I am. I can justify both cases ;)
However, I would say, Fedocal is new application, not widely used yet, so why not to postpone the push to stable and do it "right" right from beginning?
blockerbugs? I dunno. The improvement to proposing the blocking bugs is well desired feature, but we are already past alpha and we survived without it up until now ... And the loging in is new feature if I am not mistaken, so why not do it better?
Moving forward, we might consider making it a blocker
Yes
, especially once we have other things moved over to openid already, but I don't want to change the goal posts for existing apps in the middle of the process.
I agree, it should not be retroactive.
Vít
On Thu, Apr 25, 2013 at 11:31 AM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 25 Apr 2013 09:11:00 -0400 seth vidal skvidal@fedoraproject.org wrote:
Well I think the idea is simple enough - if there is one, branded and obvious login page - and that page is openid then we're not training our users to type their passwords into random websites.
Right. I think this is definitely where we are headed, but we aren't there yet. ;(
So, yes, I think we need to add support to fedocal and blockerbugs for openid, but not sure it's a blocker for them moving to production now.
-1 blocker. We've discussed this numerous times. We can't keep changing
our mind about it; it's not fair to the application developers. They follow the existing guidance about not typing your fedora password into a non-Fedora site so they're in compliance with the current best practices. People who can't stand to type their password into them also shouldn't be typing their password into the wiki, pkgdb, bodhi, and etc -- so really, they can't be Fedora contributors if they're drawing the line this strictly.
Moving forward, we might consider making it a blocker, especially once we have other things moved over to openid already, but I don't want to change the goal posts for existing apps in the middle of the process.
Yeah, with emphasis on the once other things have moved over, I could probably agree with this. There are some bumpy spots though -- for instance, what happens when an app doesn't have openid support. We also need to be aware that this can be an invasive request. If an application needs to have authz (groups or permissions) then we may not be able to get away with simple openid authn in the application and may need to code our own thing to handle that. We also need to have a certain number of other deployments done to feel confident that openid-for-our-own-apps isn't going to hit any unexpected difficulties. Lack or certain information from fas, inability of openid to scale, insecurities, etc.
-Toshio
On Fri, Apr 26, 2013 at 11:10:33 -0700, Toshio Kuratomi a.badger@gmail.com wrote:
On Thu, Apr 25, 2013 at 11:31 AM, Kevin Fenzi kevin@scrye.com wrote:
Yeah, with emphasis on the once other things have moved over, I could probably agree with this. There are some bumpy spots though -- for instance, what happens when an app doesn't have openid support. We also need to be aware that this can be an invasive request. If an application needs to have authz (groups or permissions) then we may not be able to get away with simple openid authn in the application and may need to code our own thing to handle that. We also need to have a certain number of other deployments done to feel confident that openid-for-our-own-apps isn't going to hit any unexpected difficulties. Lack or certain information from fas, inability of openid to scale, insecurities, etc.
If we used SAML, the IdP can provide group membership information which could be used by SPs for authz.
On Fri, Apr 26, 2013 at 01:57:17PM -0500, Bruno Wolff III wrote:
On Fri, Apr 26, 2013 at 11:10:33 -0700, Toshio Kuratomi a.badger@gmail.com wrote:
On Thu, Apr 25, 2013 at 11:31 AM, Kevin Fenzi kevin@scrye.com wrote:
Yeah, with emphasis on the once other things have moved over, I could probably agree with this. There are some bumpy spots though -- for instance, what happens when an app doesn't have openid support. We also need to be aware that this can be an invasive request. If an application needs to have authz (groups or permissions) then we may not be able to get away with simple openid authn in the application and may need to code our own thing to handle that. We also need to have a certain number of other deployments done to feel confident that openid-for-our-own-apps isn't going to hit any unexpected difficulties. Lack or certain information from fas, inability of openid to scale, insecurities, etc.
If we used SAML, the IdP can provide group membership information which could be used by SPs for authz.
We looked into SAML at one point and decided not to use it. I can't remember the details though.
From looking around very briefly, I'm not sure that very many things have out-of-the-box support for SAML So we'd probably have to write something to use SAML for each app instead of having to write something to use the teams OpenID extension where necessary. That seems like more work overall.
-Toshio
On Fri, 2013-04-26 at 13:57 -0500, Bruno Wolff III wrote:
If we used SAML, the IdP can provide group membership information which could be used by SPs for authz.
I didn't know what SAML was yesterday, so I checked out wiki which says:
""" The single most important problem that SAML addresses is the web browser single sign-on (SSO) problem. Single sign-on solutions are abundant at the intranet level (using cookies, for example) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies. (Another more recent approach to addressing the browser SSO problem is the OpenID protocol.) """
From this, it seems OpenID might be a better fit.
Pierre
Have been involved in various SAML efforts on the RH side, happy to discuss further if folks are interested.
--Bret
----- Original Message -----
On Fri, 2013-04-26 at 13:57 -0500, Bruno Wolff III wrote:
If we used SAML, the IdP can provide group membership information which could be used by SPs for authz.
I didn't know what SAML was yesterday, so I checked out wiki which says:
""" The single most important problem that SAML addresses is the web browser single sign-on (SSO) problem. Single sign-on solutions are abundant at the intranet level (using cookies, for example) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies. (Another more recent approach to addressing the browser SSO problem is the OpenID protocol.) """
From this, it seems OpenID might be a better fit.
Pierre _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, Apr 26, 2013 at 01:57:17PM -0500, Bruno Wolff III wrote:
If we used SAML, the IdP can provide group membership information which could be used by SPs for authz.
Our OpenID implementation does this as well with the teams extension, and also provides CLA information with the CLA extension.
Patrick
On Thu, 25 Apr 2013 10:07:25 +0200 Vít Ondruch vondruch@redhat.com wrote:
Hi guys,
Since you want to push Fedocal and Blocker tracking into production, would you mind to change you login forms, that I don't have to enter my FAS password into your application dialog boxes? Although I understand that they are Fedora's application, hosted on Fedora's infrastructure, etc. , I don't feel comfortable to enter my FAS password into various applications, which I consider 3rd party from this perspective.
Similar to fedocal, we're planning to migrate blockerbugs over to openid before F20 but that's a non-trivial change and I imagine that you'd still be concerned about our use of bugzilla passwords even if we were using openid.
On the bright side, the only thing that the blockerbugs app uses the password for is to propose blocker/fe bugs and that can still be done manually in bugzilla.
Out of curiosity, what do you consider to be FAS password-using apps which are not 3rd party?
Tim
SAML is indeed one method of passing a secure token to another app/service. Implementing SSO would probably be a great move forward to consolidate your source of truth for Fedora users in one location.
Whatever mechanism you choose to use to implement SSO, you need to consider the ease to integrate it with our existing applications. This will likely be a code change for many applications.
C On Apr 25, 2013 4:07 AM, "Vít Ondruch" vondruch@redhat.com wrote:
Hi guys,
Since you want to push Fedocal and Blocker tracking into production, would you mind to change you login forms, that I don't have to enter my FAS password into your application dialog boxes? Although I understand that they are Fedora's application, hosted on Fedora's infrastructure, etc. , I don't feel comfortable to enter my FAS password into various applications, which I consider 3rd party from this perspective.
Thank you.
Vít ______________________________**_________________ infrastructure mailing list infrastructure@lists.**fedoraproject.orginfrastructure@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/**infrastructurehttps://admin.fedoraproject.org/mailman/listinfo/infrastructure
infrastructure@lists.fedoraproject.org
-
Bret McMillan -
Bruno Wolff III -
Chris Dix -
Kevin Fenzi -
Patrick マルタインアンドレアス Uiterwijk -
Pierre-Yves Chibon -
Seth Vidal -
Tim Flink -
Toshio Kuratomi -
Vít Ondruch