[Icecast-dev] [Icecast] Micro Guide to Understanding Icecast 2.5.x authentication (For Icecast 2.5 beta 3)
Thomas B. Rücker
thomas at ruecker.fi
Fri Feb 15 13:09:20 UTC 2019
Sorry, this obvious malware/virus slipped through. :-(
Please delete that previous email / ignore it.
TBR
On 2/7/19 9:30 AM, IVY Nelson wrote:
> Morning,
>
> See the attached document.
>
> Pass 1234567.
>
> ------------------------------------------------------------------------
> *From:* phschafft at de.loewenfelsen.net
> *Sent:* Fri, 09 Nov 2018 11:10:22 +0000
> *To:* icecast-dev at xiph.org, icecast at xiph.org
> *Subject:* [Icecast] Micro Guide to Understanding Icecast 2.5.x
> authentication (For Icecast 2.5 beta 3)
>
> Good morning,
>
> as there has been some confusion I thought it might be best to write
> some little "Micro Guide" for Icecast 2.5.x's authentication subsystem.
> This E-Mail refers to not yet released version 2.5 beta 3 (to be
> released soon).
>
> !!! /!\ !!!
> If you run Icecast 2.4.x (stable) this E-Mail is not relevant to you!
> !!! /!\ !!!
>
>
> Overview
> Icecast 2.5.x changed the authentication system very much since
> Icecast 2.4.x. But good news first: Icecast 2.5.x can read
> Icecast 2.4.x config files and will behave correctly.
>
> The new system works by a set of rules. Rules are tried from top
> to bottom. The first one that matches wins. When a rule matches
> a set of access control parameters are set.
>
> Rules can be defined by (and tried in this order):
> * listen sockets (<listen-socket>),
> * normal mounts (<mount type="normal">),
> * default mounts (<mount type="default">),
> * the global list (<icecast>).
>
> Each of those blocks can contain a <authentication> subtag.
> (Note: It must not set a type="", otherwise it will be
> interpreted as Icecast 2.4.x config).
>
> Each such <authentication> can contain a number of <role> tags.
> Each <role> tag defines a rule.
>
> A <role> tag can include <option>, and <http-headers> tags.
> <option> tags are used to define additional options for the used
> backend the same way as they did in 2.4.x.
>
> Examples can be found at the end of this E-Mail.
>
> Defining a role
> A <role> represents a rule in the system. The servers will try
> all related <role>s when a client connects in from top to
> bottom.
>
> A role may contain filters on parameters of the client. Such as
> the request method. By default no filters are used.
>
> When the role's filters match the request (or no filters are
> set) the configured backend is asked. Such backends include
> static username/password sets or more empowered backends such as
> the URL auth backend.
>
> The will report a positive (success) or negative match (access
> deny) or no-match (the next rule is tried).
>
> When a role returned a negative match access to the requested
> resource is denied.
>
> When a positive match is returned the given access control rules
> are applied.
>
> Defining access control rules
> Access control rules can be defined as part of the <role> tag.
>
> There currently are the following access parameters that can be
> set:
> * which HTTP methods are allowed (such as GET or PUT)
> (allow-method, deny-method; default: allow only GET and
> OPTIONS),
> * which admin/ commands are allowed (allow-admin,
> deny-admin; default: allow only buildm3u (playlist
> generation)),
> * if web/ access (that is the status page and the actual
> streams) is allowed (allow-web, deny-web; default: allow
> web access),
> * how many simultaneous connections can be made by a user
> (connections-per-user; default: unlimited connections),
> * how long a listener might listen to a stream before
> being automatically disconnected (connection-duration;
> default: unlimited time).
>
> Examples:
> Consider the following global <authentication> block:
> <authentication>
> <role type="static" allow-all="*" >
> <option name="username" value="admin" />
> <option name="password" value="hackme" />
> </role>
> <role type="static" allow-web="*" deny-admin="*" >
> <option name="username" value="listener" />
> <option name="password" value="salad" />
> </role>
> <role type="anonymous" deny-all="*" />
> </authentication>
>
> This first checks for a user with the username "admin" and the
> password "hackme". If the client sent those credentials it
> allowd to have full access (allow-all="*").
>
> Then the server checks for the user with username "listener" and
> password "salad". If the client sent those credentials to the
> server it is allowed web access (and listening to streams)
> (allow-web="*") but no admin access (deny-admin="*").
>
> If no of the above rules match the last rule matches and forbids
> all access (deny-all="*").
>
>
> Now let's consider the following additional block:
> <mount type="normal">
> <mount-name>/example1.ogg</mount-name>
> <authentication>
> <role type="static" allow-web="*">
> <option name="username"
> value="friend" />
> <option name="password" value="wine" />
> </role>
> </authentication>
> </mount>
>
> This <mount> block configures the mountpoint "/example1.ogg". It
> contains a <authentication> with a single <role>.
>
> Let's see what happens:
>
> Now if a client connects to this specific mount point it is
> first checked if it's our friend "friend" with the password
> "wine". If it's our friend we allow listen him to listen to the
> stream as well.
>
> Here no rule for admin access has been defined, so the default
> value is used: Allow playlist generation only.
>
> If the client is not our friend, the rules from the global
> section are tried.
>
>
> Our last example will disable admin access on a given listen
> socket (e.g. for restricting it to an internal interface). We do
> this by applying a filter.
>
> Consider the following block:
> <listen-socket>
> <bind-address>192.0.2.137</bind-address>
> <port>8000</port>
> <authentication>
> <role type="anonymous" match-admin="*"
> nomatch-web="*" deny-all="*" />
> </authentication>
> </listen-socket>
>
> In this example all clients that request admin any admin
> commands (match-admin="*") but no clients requesting web/
> resources (nomatch-web="*") are rejected (deny-all="*").
>
> Conclusion and looking forward
> The new authentication subsystem is very powerful and can be
> used for complex setups. However it requires more understanding
> of rule based access control.
>
> The new and the old style configs can freely be mixed to enable
> both a smooth transition as well as make simple setups keep
> simple (e.g. by using the old style <source-password> tag).
>
> We currently work on ways to make the config a bit simpler and
> also to document things better. This E-Mail is a first part of
> this.
>
> There are a lot more options that have not been covered in this
> E-Mail such as more complex matching setups or backend based
> client rewrites.
>
> There are also some more ideas for the future features such as
> better integration of <resource>[0][1] or optimizations to keep
> load off the actual backend by handling challenge requests
> internally.
>
> I'm happy to answer all questions and looking forward to any feedback!
>
> With best regards,
>
>
> [0] Previously known as <alias>. Has been improved a lot!
> [1] Maybe worth another E-Mail? Let me know if there is interest.
>
> --
> Philipp Schafft (CEO/Geschäftsführer)
> Telephon: +49.3535 490 17 92
>
> Löwenfelsen UG (haftungsbeschränkt) Registration number:
> Bickinger Straße 21 HRB 12308 CB
> 04916 Herzberg (Elster) VATIN/USt-ID:
> Germany DE305133015
>
>
> _______________________________________________
> Icecast-dev mailing list
> Icecast-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast-dev/attachments/20190215/eedaaf16/attachment-0001.html>
More information about the Icecast-dev
mailing list