Meeting Agenda Item: Introduction Akshay Sharma
by Akshay Sharma
Hello Everyone,
My name is Akshay Sharma and i am a beginner IT Student in India.My age is 19 years.
I am really interested to work with the fedora project community.I know programming in java and C++
and are interested in the development work for Fedora.I like to join the Infrastructure team to provide
support to other team members and community. Since i don't have any great prior experience but i will
try to learn as much as possible with your help and will give my best that i can do for the Fedora Community
Akshay Sharma
11 years
Oauth -- shall we start using this?
by Toshio Kuratomi
So in the past week a bunch of us have been talking about API Keys, OAuth,
passwords, and other means of managing authn and authz in the web apps that
are up and coming (specifically mentioned were copr and datagrepper).
Puiterwijk has put in some time reading the OAuth specifications and on
Friday he walked me through how OAuth is supposed to work. I'll give a
summary of his talkl here and then we can kick off some discussion.
OAuth is a standardized method for a user to grant access to resources that
they own to people and things that are not themselves. Currently this is being
used to allow a user to control the access to data and actions that may be
performed on one web service by another web service. The concepts and
mechanisms can be used in any situation where the user wants to limit what the
software they are using can do on their behalf.
= Part I: What is OAuth? =
== Let's name all the things ==
* Protected Resource is either data or a function that you want to use.
* Resource Server is the server that hosts the data.
* Client is the program that needs access to the Protected Resource.
* Resource owner is the person (may also be a system but well concentrate on
actual people for this summary) who is authorized to grant clients access to
the Resource.
* Authorization Server is the server that grants tokens and codes.
.. note:: `access` is used to mean that the client can use the protected
resource. That usage might cause changes to data or cause other actions to
be taken (like kicking off a build). be careful not to read `access` as
"ability to read the data".
Example time:
There's a resource called 'full name of toshio'. It's hosted on the Fedora
Account System so FAS is the resource server. Since toshio is my account, I am
the resource owner for it. When I log into the PackageDB, PackageDB wants to
display my full name to greet me. PackageDB needs to contact FAS for that
information. Thus PackageDB is the client. If we create an OAuth server, that
server will be the Authorization Server that verifies my identity and asks me
to grant access to 'full name of toshio' to the PackageDB. Once I've done so,
it will issue the tokens and codes that actually let the PackageDB get the
information it wants from FAS.
== Flow of a basic request from start to finish ==
* The client program needs to get access to a protected resource.
* The client asks the authorization server for a client-id and tells the server
which permissions it needs
* The authrization server gives a url to the client
* The client program redirects the user to that url so the user can grant
permissions to the client
* The authorization server authenticates the user (ie: they login to the
authorization server).
* The authorization server asks the user to confirm they want to grant the
requested permissions to the client.
* If the answer is no, the protocol ends.
* If he answer is yes, the user is redirected to the client with an
`authorization code` in the request
* The client sends the `authorization code` to the authorization server.
* The authorization server generates an `access token` with the specific
permissions that the client requested, expires the `authorization code`, and
returns the `access token` to the client,
* The client requests the protected resource from the resource server using the
`access token`.
* The resource server verifes that the `access token` is valid. If it is, it
allows access
.. note:: the `authorization code` is only good for retrieving a single
`access token` for the particular set of permissions that the user
confirmed.
.. note:: A client can request access to multiple resources at once. Assuming
the resource owner accepted all of them, the access token the client
receives at the end will allow access to all of those. A client typically
has one access token from an authorization server that grants it all needed
permissions on all of the resource servers that the authorization server
can give out permissions for. It is possible for a client to have multiple
access tokens with different permissions from the same authorization server
but the client would have to keep track of which permissions were granted
by which token (and the user would have had to confirm that the client
should be granted each set of permissions).
.. question:: an access token can contain permissions for multiple resource
servers. How do we secure the token from being used maliciously by a
different resource server? ie: I get an access token which grants some
permissions on both fas and bodhi. I send that access token to fas to
retrieve some information. What prevents fas from hanging onto that token
and using it to access the protected resources on bodhi that it grants
without my knowledge?
== But wait, there's more! ==
We've now seen one authorization via oauth. But Oauth is flexible. There's a
few different ways this can work to be aware of:
* Other ways to request the access token. The example above is what works best
for third-party web clients. However, there's other flows that might work
better for CLI apps or "trusted" web clients
- Implicit: user gets the access token directly from the authorization server
rather than through a authorization code. This sortcut is useful when the
client is entirely in the browser (no third-party server involved). With a
third party server, the authorization code makes it so the user never sees
the actual access token, only the authorization code. if the client is
running on the user's machine anyhow, there's no sense in that step.
- Resource owner password credentials: The resource owner provides their
credentials (username and password) to the client. The client retrieves
the access token from the authorization server using the credentials. Then
it discards the credentials and only keeps the access token for further
requests.
- Client credentials: Just defines that if the client is the resource server,
it can authenticate itself to access its own resources... I'm a little
unclear on this but I think one use would be for a resource server to use
its externally available functions (which are protected by oauth) rather
than having to write an equivalent function that is usable internally.
puiterwijk mentions a different use: having a strict separation between
tenants in the resource server's model and then having to prove you have
permission to access the resource from a different tenant (not something
we're likely to do).
* Verification of the access token can take many forms.
- The authorization server could notify the resource server whenever a new
access token is issued/revoked
- The resource server could ask the authorization server to verify the token
each time it receives one
- The token could be signed by the auth server and thus be verifiable in and
of itself. The token could then contain the list of permissions so that
the resource server would just consult the token to know what was
available. This should not be preferred as it makes revoking a token
harder.
* The authorization server may or may not know about the range of permissions
that it can grant. The resource server needs to interpret what the
permissions the access token grants mean so if the authorization server
grants a made-up permission the application should just ignore it.
.. question:: Is it possible for the user to grant some of the requested
permissions and deny others? Or is it all or nothing?
== Refreshing a token and its caveats ==
An access token can have an expire time. The expire time can be coupled with a
second token called a refresh token. Usually the refresh token would expire
sometime after the access token would expire. When the access token expires,
the refresh token could be used by the client to request a new access token
without prompting the user. This is indended to protect against an attacker
who is sniffing packets from amassing enough ciphertext from multiple uses of a
single access token to be able to brute force that token.
This sort of automatic expiration and refresh **is not** meant to protect the
user in case the access token is copied without their knowledge (because the
refresh token can be copied at the same time).
= Part II: How do we use this? =
This section is less about OAuth itself but some proposals about how we can
best code OAuth usage in our web applications to be secure and featureful.
== Session vs token ==
Currently we have a concept of a session in all of our web apps. You login.
Once you're logged in, the web app knows that future connections from your web
browser/CLI/etc are being made by you. At some point the session expires or
you explicitly log out. At that point, the session is over. The expiration
time for most of our apps is currently 20 minuts of idle time but we've talked
about increasing this in the past. Sessions in my mind should last tens of
minutes to hours. Certainly no more than a day. A session conceptually tells
the server that the user is present and interacting with the website (by saying
that the user has "recently" authenticated).
Tokens are more akin to passwords coupled with a restricted set of permissions.
They're intended to be valid for days to weeks. Refresh tokens can (but don't
necessarily) be used to keep a low amount of ciphertext in the system while
still making authentication via access token transparent to the client.
Conceptually, they tell the server that the **client** (not user) is the same
one that was granted the permissions.
=== Using tokens to implement sessions ===
* Sessions need to be short term -- expiration would need to be low (perhaps an
hour). No possibility to refresh the token. If you need to continue, you
have to re-send your username + password (+ otp?)
* We want this specific token to represent that the user is present, not just
that the client has been delegated permissions.
* It would make sense for the token to give out all permissions that the user
has (at least, on this resource server) because the user is present. Example
token permission: "*@*" permissions token
* If possible, saving this type of session token into a wallet/keyring would
make sense as that would encrypt the on-disk representation. However, we'd
also have to account for the fact that these services might not be present.
* Suggested to have access tokens with validity of 5 minutes. refresh tokens
of 20 minutes. This would approximate our current cookie-based idle timeout.
.. question:: Can we also have a maximum number of refreshes or maximum time
before the user has to reenter their credentials (username + password
(+otp?))
== Some proposed best practices ==
* Oauth allows for very granular permissions. You could put a separate
permission on each resource that a client can request. However, it doesn't
require that you are granular or not because the application interprets the
meaning of the permission. A lazy resource server could have a single
permission that covered anything that can be performed on the server but this
means that a stolen token can be used to do anything that that user could do
on that resource server. We should attempt to identify common use cases and
code separate permissions for them. ie: "building a package in a copr" would
belong in a separate permission from "creating a new copr".
* An access token should not be taken to represent the presence of the user.
It means the user has delegated permission to perform this action to some
"client". It is possible that the client is a command line app or an api and
the user is interacting with it directly but it cannot be assunmed that this
is the case.
* Following from that, changing authentication methods, password, yubikey,
security questions, etc should never be allowed via an access token. We want
the user to be present to change these settings.
* Tokens and sessions should not contain information about the authentication
status. They should not contain what permissions are held or when the
session expires. These are for the resource server and authorization server
to determine.
* Also following from that -- we should write things to allow for a session to
be sufficient for allowing users to perform actions. access tokens describe
a subset of the functions that the user themselves is allowed to perform.
* Client side -- we want to have different permissions if the user is running
the cli from the command line vs running the cli from a cron job. A user
running from the cli could be said to have a session.
IRC log (since this is all paraphrased and I could have misunderstood what puiterwijk meant):
http://toshio.fedorapeople.org/puiterwijk-oauth.html
-Toshio
11 years
Request for a HyperKitty instance for an early adopter (Arquillian)
by Dan Allen
The Arquillian project [1] would like to volunteer to be an early adopter
of HyperKitty. We are looking to shift from forums to mailinglists, but not
lose a user-friendly web frontend for folks just browsing for information.
We're writing to this list because we think that Fedora and Arquillian
share a common goal to see HyperKitty evolve. We can offer to hack on it
and promote it if Fedora infrastructure would be willing to give us a space
to run a public instance of it. (We're also Fedora users, of course).
We know about mm3test.fedoraproject.org, but we're hoping to be able to
point discuss.arquillian.org at to the installation (CNAME support).
We plan to actively work on HyperKitty to improve the functionality and
user experience. Therefore, we'd like to request a dedicated instance to
give us the flexibility to experiment as much as needed without having to
worry about disrupting the other lists running on it. In other words, we
want to be bleeding edge for a while :)
Let us know whether this seems like a good fit. Although we are separate
communities, I think the common goal of moving HyperKitty forward gives us
good reason to work together. Plus, we're really eager to see HyperKitty
get used for Fedora lists too.
-Dan
p.s. http://arquillian.org
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
11 years
Meeting Agenda Item: Introduction Qingwei Zhang.
by Qingwei Zhang
Dear All,
This is Qingwei Zhang, a Computer Engineering Master's student from
University of Ottawa, Canada. I am so happy that I can contribute to
the team, and here is my introduction to the team.
Name:
Qingwei Zhang
Time Zone / Country:
UTC-5(Ottawa, Ontario, Canada.)
Basic skills and experiences:
1. Intermediate C++, C, sed scripting, Makefiles
2. Professional: Shell script, Bash
3. Tools: Eclipse CDT, GDB, GNU Make, Vim,
I have LPIC-1, and more than two years experience of Linux
administration, and I have my own testing machines.
Why you're joining:
Two reasons, firstly, I like fedora, and want to do something for this
project; secondly, this experiences can strengthen my skills as
software developer.
How much time you can contribute (usually hours per week):
about 5 hours per week.
Your IRC handle:
#qzhan054
What you would like to work on and quite possibly which outstanding
issues you would like to help resolve:
I would like to learn how to create and maintain custom tools and
applications to Automate Systems Maintenance.
Currently, I think I can help with this problem: ticket #3701 (new
task) Update Fedora Product Description in Bugzilla (Branch Day).
Regarding my capacities, I am graduating in uOttawa with distinction
in computer engineering. I am well versed in Linux administration,
shell programing and computer C language. I came successful in all
projects in the last year of the course. I am a self trained man with
willingness to work for the welfare of the organization I am working,
to the utmost satisfaction of my superiors. I also am a man of strict
discipline and self restricted policies of sticking to punctuality,
dedication in work, integrity and cooperation with other colleagues.
Now I am ready work with the Fedora Infrastructure team at any time.
I am looking forward to hearing from you soon! Thank you.
Qingwei Zhang.
--
Qingwei Zhang
Do something today that your future self will thank you for.
11 years
Jenkins update
by Pierre-Yves Chibon
Hi all,
I have written this last week-end and I'm late...
I have started to write down some instruction on how one can get his/her
project added to our jenkins server:
https://fedoraproject.org/wiki/Jenkins@infra
And (attached) I wrote a small SOP on how we should handle this.
These two documents are up for review, discussion and correction.
Please fire away :)
Thanks,
Pierre
11 years
vfad - virtual fedora activity day ideas
by Seth Vidal
Hi,
We discussed this today in the infra meeting: We've had some success
with FADs - fedora activity days - most recently for 2-factor-auth.
FADs let us focus on a specific task and knock it out by having all the
stakeholders together in one place and all ready to only do achieve one
goal. The problem is they require people all come to one location and
we have hotels to put people in, etc. Which is not only expensive but a
giant pain in the ass. :)
I'd like for us to try out a VFAD where we act like we are in a FAD but
we don't go anywhere. We come together in a single irc channel. We tune
out our other msging channels. We all gather on a single google hangout
or conference call so we can just yell at each other when needed.
In short we use all the high-bandwidth things we can to provide access
to each other but from remote locations.
so we discussed ideas of what to do on such days and a lot of ideas
came out of it (in no particular order)
- application logging/logging in general
- enhancing our trending/analysis
- making our web app logging not be so much pain
- making sure our logs are complete and legible
- 2fa in apps
- making all of our apps use 2fa if available
- app/appserver break out
- breaking our apps from grouped app## servers into individual
application instance (tagger##, bodhi##, etc)
- helps with isolating where problems actually live
- ansible migration
- cli logins for web apps
- dealing with our decisions on tokens or oauth, etc and implementing
it
- fedorahosted-ng
- the next iteration of fedorahosted and what we need to add to make
it fast/better/great
- IDS
- intrusion detection
- db-replication/SPOF-removal
- right now our db servers are our major single-point-of-failure
- replicate our db servers
- better failover conditions
- nagios
- automating more of nagios
- handling errors better
- cloud-productionizing
- things to make our cloud fully production
Other ideas?
Please let us know what you think and add ideas.
-sv
11 years
Plan for tomorrow's Fedora Infrastructure meeting (2013-03-07)
by Kevin Fenzi
The infrastructure team will be having it's weekly meeting tomorrow,
2013-03-07 at 19:00 UTC in #fedora-meeting on the freenode network.
Suggested topics:
#topic New folks introductions and Apprentice tasks.
If any new folks want to give a quick one line bio or any apprentices
would like to ask general questions, they can do so in this part of the
meeting. Don't be shy!
#topic Applications status / discussion
Check in on status of our applications: pkgdb, fas, bodhi, koji,
community, voting, tagger, packager, dpsearch, etc.
If there's new releases, bugs we need to work around or things to note.
#topic Sysadmin status / discussion
Here we talk about sysadmin related happenings from the previous week,
or things that are upcoming.
#topic Private Cloud status update / discussion
#topic Upcoming Tasks/Items
#info 2013-03-07 remove inactive apprentices.
#info 2013-03-12 to 2013-03-21 pycon
#info 2013-03-19 to 2013-03-26 - koji update
#info 2013-03-29 - spring holiday.
#info 2013-04-02 to 2013-04-16 ALPHA infrastructure freeze
#info 2013-04-16 F19 alpha release
#info 2013-05-07 to 2013-05-21 BETA infrastructure freeze
#info 2013-05-21 F19 beta release
#info 2013-05-31 end of 1st quarter
#info 2013-06-11 to 2013-06-25 FINAL infrastructure freeze.
#info 2013-06-25 F19 FINAL release
#topic Open Floor
Submit your agenda items, as tickets in the trac instance and send a
note replying to this thread.
More info here:
https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings
Thanks
kevin
11 years
Introduction
by Alexander Rudolf
Hi folks,
I would like to introduce myself too:
First of all I would like to give a "thanks a lot" and "wow - great
job!!!" to all who have made fedora become reality!!! It is fun to work
with it.
My name is Alexander Rudolf. I live in Germany. I am an IT
infrastructure consultant and systems engineer working for a company in
Dresden, Saxony.
"Growed up" (I am 39) with MS-DOS an Novell NetWare in the early 90s
when I started my work live I now have a lot experience with
heterogeneous networks, network equipment and security, systems
management, high availability solutions and those things. Made my MCSA
for Windows Server and am LPI-C certified since 2006.
My most recent experiences are in Linux system administration, security,
virtualization and most of all - Nagios. I supported a number of related
projects for some customers and wrote a couple of Nagios plugins. Most
of them in bash, but also in VBS and PowerShell for the windows driven
landscape.
I would now like to actively join the fedora infrastructure team and do
my very best to provide support. Please help me to understand how I can
contribute best!
Best regards,
Alex
11 years