search

ansible / awx

AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.
Other
14.12k stars 3.44k forks source link

Feature: Token-based authentication to AWX #21

Closed wenottingham closed 6 years ago

wenottingham commented 7 years ago

AWX Feature Spec - Token-based authentication to AWX

User Persona

AWX administrator configuring AWX integrations with other services

Usage Cases

Administrator is used to Slack/Trello/etc. and other services that use authentication tokens rather than a user/password combo to authenticate to API services. AWX should support this use case.

Authentication tokens should either:

If tied to a user, a user should be able to create and revoke their own tokens. Token access/usage should be logged.

API Considerations

Suggested implementation: https://github.com/evonove/django-oauth-toolkit

UI/UX Considerations

TBD based on API work.

Docs

QA Suggestions

Notes

Updates/Changelog

2017-09-06: Initial version

matburt commented 7 years ago

This seems very much in line with a direct oauth2 integration.

An administrator would be able to define "apps" (aka providers) and users would be able to authenticate using those given the provider key and secret as well as their username and password (or something else depending on the grant type). This returns a token to the user that they could use in place of their username and password when interfacing with AWX itself. The expire time of these tokens can be long-lived (also, configurable)

An extra feature we could pick up would also be becoming an SSO provider (like SAML/whatever) for authenticating to other systems via a 2-legged process.

A bigger question is what does this do about our current Token auth scheme? Our basic-auth usage? Potentially moving towards Session based authentication for the UI? We'll have to solve these here.

akcrisp commented 7 years ago

Hi is there any update or proposed future version for this ?

matburt commented 7 years ago

We'll start specing this out more soon, stay tuned

AlanCoding commented 7 years ago

be a toplevel item akin to a user, and be able to be assigned permissions directly

This returns a token to the user that they could use in place of their username and password when interfacing with AWX itself.

Out of the 2 alternative implementations, I'm worried about the comparatively large surface area that allowing the token to "act as the user" would expose.

Consider the callback tokens, and how extremely limited they are. They don't even let you make a GET request to the callback endpoint (only POST, and only from a particular IP). If you make a user and strip everything out (not a member of any organization, has no permissions), you still expose a good deal of the API to them. They can GET most list views, and most OPTIONS requests. They can also create items in the database, specifically credentials.

I would expect many uses of tokens would be for particular limited actions, like launching a job template.

matburt commented 7 years ago

be scoped to a particular user, and inherit that user’s permissions is more like what we want to support.

be a toplevel item akin to a user, and be able to be assigned permissions directly is more like service accounts which we may want to support but is out of scope for this.

Speaking of scope, the oauth library we want to use does support scoping such that we could dynamically constraint what it can do relative to the user who is using it.

wwitzel3 commented 7 years ago

Here are some notes from a recent planning conversation about this.

Likely we will have a 1-to-1 of our RBAC roles to scopes. This initial implementation will NOT have Tower act as an OAuth2 SSO provider. UI for OAuth2 will be in the Settings area of Tower

Actions

RBAC Considerations

Preexisting Auth

Docs

akcrisp commented 7 years ago

Would it help if I explained our initial requirement for this ?

Sent from my iPhone

On 17 Oct 2017, at 20:15, Wayne Witzel III notifications@github.com wrote:

Here are some notes from a recent planning conversation about this.

Likely we will have a 1-to-1 of our RBAC roles to scopes. This initial implementation will NOT have Tower act as an OAuth2 SSO provider. UI for OAuth2 will be in the Settings area of Tower

Actions

Create Applications List Applications Enable/Disable applications Create application token List application tokens Revoke application tokens RBAC Considerations

Who can create new applications? System level apps Organization level apps New RBAC role for creating applications? Scopes will be applied along side RBAC permissions and the move restrictive set of permissions will be used Example Application RBAC - Project Admin User + OAuth2 Project Read Scope Project Read = token is project read (no write) Preexisting Auth

Keep basic auth (note, there will be no support for using basic auth in the UI) Remove old /authtoken (bobby drop table) Switch to session based authentication (no more token passing) Look at session limits / properties (timeouts, max concurrent) Session table cleanup jobs Docs

Provide some cURL and Python requests examples: creating app generating a token making an API request Show examples of management commands — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

wenottingham commented 7 years ago

Can't hurt to hear about use cases - how would you be looking to use tokens?

akcrisp commented 7 years ago

So we need to be able to drive creation of inventories / projects and job templates from external systems. In our initial requirement this is for os patching. We have a patching portal where end users will book their systems into to be patched on a given date. We then need the ability via api call to have ansible generate an inventory of the hosts to be patched on that date and to then create and schedule a job template for those hosts. The patching portal will then query ansible for status of the completed job, so we can see which hosts have failed or succeeded. We can do all of this now - what’s holding us back is having to supply a password to access the api.

Sent from my iPhone

On 18 Oct 2017, at 16:29, Bill Nottingham notifications@github.com wrote:

Can't hurt to hear about use cases - how would you be looking to use tokens?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

matburt commented 7 years ago

Sounds like generic api access to me. We'll be replacing our existing token system with one based on oauth2 so you'll be able to define an oauth2 app in AWX and then get a token from it given a particular user... that token can have a much longer life than our current ones so you'll be able to just store the token without having to constantly re-auth.

mabashian commented 7 years ago

UI implication notes:

jangsutsr commented 7 years ago

API TODO list:

akcrisp commented 7 years ago

Hi do we have an eta for when we expect this to be available ?

Thanks

Andy

wenottingham commented 7 years ago

Like most open source things - when it's done. If you are concerned about it from a release schedule of Red Hat supported products... contact your support rep/TAM/etc.

akcrisp commented 7 years ago

[edited for code of conduct]

gregdek commented 7 years ago

@akcrisp edited your previous comment. feel free to reach out to me for reasoning, gdk@redhat.com, thanks.

akcrisp commented 6 years ago

guys I've started looking at this implementation in 1.0.6. Now I will be first to admit that I am new to oauth2 however reading the docs referenced from here:- https://groups.google.com/forum/#!topic/awx-project/kjlXPyc2YwE. I am still puzzled how this will actually work in practice - as it appears that in order to get access to the api it will check if the user is logged in, and will prompt asking them to grant access ? Or is this dependent on the grant type ? ie implicit will not ?

Can someone confirm its entirely possible for us to programmtically gain access to the api without it prompting or requiring any user input ? Is there any documentation giving an example of configuring this including defining the application in awx wih the redirect_uris ?

akcrisp commented 6 years ago

Reading this exchange - https://groups.google.com/forum/#!topic/awx-project/LcyEosimwZg

If I read that correctly still implies it requires an initial password to do programmatically ? Can someone confirm if i am missing the point drastically ?? @wenottingham @matburt @rooftopcellist

rooftopcellist commented 6 years ago

Hi Akcrisp,

Like you mentioned, the authorization flow depends on your grant type, but you will need to have already created a user in AWX to acquire a token no matter what grant type you use.  For programmatically creating an OAuth2 token you will want to use a “password” grant type.  Here is an example curl to make a “password” grant application:

curl -ku user:password -H "Content-Type: application/json" -d '{"name": “Akcrisp Application", "client_type": "confidential",       "authorization_grant_type": "password", "organization": 1}' -X POST http://localhost:8013/api/v2/applications/ 

This will return a client_id an client_secret for the newly created “password” grant type application.  You can use a curl like this to acquire a token for that application: 

curl -X POST \
  -d "grant_type=password&username=<user>&password=<password>&scope=read" \

  -u “:" \   http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).  

Thanks, Christian

Christian M. Adams Associate Software Engineer at Ansible - Red Hat University of North Carolina at Chapel Hill, Class of 2014 chadams@redhat.com  |  (919) 218-5080  |  GitHub: rooftopcellist

On May 22, 2018 at 10:35:47 AM, akcrisp (notifications@github.com) wrote:

Reading this exchange - https://groups.google.com/forum/#!topic/awx-project/LcyEosimwZg

If I read that correctly still implies it requires an initial password to do programmatically ? Can someone confirm if i am missing the point drastically ?? @wenottingham @matburt @rooftopcellist

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

akcrisp commented 6 years ago

Ok and when setting up the application in the awx gui what grant type do I use as there isn’t one called “password” ? This is 1.0.6.8 build. If I create it in the awx gui I assumed the tokens would then appear under the token tab ? However there was nothing when I created it (implicit grant type I tried).

Is the redirect_uris always the same ( http://localhost:8013/api/v2/applications/) ?

And by created user in awx I assume this works if the account in question is actually in AD and awx is looking the users up via ldap as configured in gui ?

Thanks

Andy

Sent from my iPhone

On 22 May 2018, at 20:15, Christian Adams notifications@github.com wrote:

Hi Akcrisp,

Like you mentioned, the authorization flow depends on your grant type, but you will need to have already created a user in AWX to acquire a token no matter what grant type you use. For programmatically creating an OAuth2 token you will want to use a “password” grant type. Here is an example curl to make a “password” grant application:

curl -ku user:password -H "Content-Type: application/json" -d '{"name": “Akcrisp Application", "client_type": "confidential", "authorization_grant_type": "password", "organization": 1}' -X POST http://localhost:8013/api/v2/applications/

This will return a client_id an client_secret for the newly created “password” grant type application. You can use a curl like this to acquire a token for that application:

curl -X POST \ -d "grant_type=password&username=&password=&scope=read" \ -u “:" \ http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).

Thanks, Christian

Christian M. Adams Associate Software Engineer at Ansible - Red Hat University of North Carolina at Chapel Hill, Class of 2014 chadams@redhat.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 10:35:47 AM, akcrisp (notifications@github.com) wrote:

Reading this exchange - https://groups.google.com/forum/#!topic/awx-project/LcyEosimwZg

If I read that correctly still implies it requires an initial password to do programmatically ? Can someone confirm if i am missing the point drastically ?? @wenottingham @matburt @rooftopcellist

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

rooftopcellist commented 6 years ago

Hi Andy,

The full name in the UI is Resource owner password-based grant type. There is no need for a redirect_uri to be specified for this grant type.

You will have to create tokens for the application you have made, either through the browsable API, or with a curl. For example, if you go to http:///api/v2/tokens/ and post the following JSON, you will see a token appear in the UI.

{ "description": "My First App Token", "application": 1, <<< or the id of your application "scope": "write" }

When you create an application, it does not automatically create a token. The UI does not currently support Token creation. This will work with user populated into awx using ldap as well. The token will assume all of the permissions that user has if given the write scope.

Thanks, Christian

Christian M. Adams University of North Carolina at Chapel Hill, Class of 2014 BA Chemistry, BM Music Performance | Sound Engineer at Continuum Audio rooftopcellist@gmail.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 3:48:25 PM, akcrisp (notifications@github.com) wrote:

Ok and when setting up the application in the awx gui what grant type do I use as there isn’t one called “password” ? This is 1.0.6.8 build. If I create it in the awx gui I assumed the tokens would then appear under the token tab ? However there was nothing when I created it (implicit grant type I tried).

Is the redirect_uris always the same ( http://localhost:8013/api/v2/applications/) ?

And by created user in awx I assume this works if the account in question is actually in AD and awx is looking the users up via ldap as configured in gui ?

Thanks

Andy

Sent from my iPhone

On 22 May 2018, at 20:15, Christian Adams notifications@github.com wrote:

Hi Akcrisp,

Like you mentioned, the authorization flow depends on your grant type, but you will need to have already created a user in AWX to acquire a token no matter what grant type you use. For programmatically creating an OAuth2 token you will want to use a “password” grant type. Here is an example curl to make a “password” grant application:

curl -ku user:password -H "Content-Type: application/json" -d '{"name": “Akcrisp Application", "client_type": "confidential", "authorization_grant_type": "password", "organization": 1}' -X POST http://localhost:8013/api/v2/applications/

This will return a client_id an client_secret for the newly created “password” grant type application. You can use a curl like this to acquire a token for that application:

curl -X POST \ -d "grant_type=password&username=&password=&scope=read" \ -u “:" \ http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).

Thanks, Christian

Christian M. Adams Associate Software Engineer at Ansible - Red Hat University of North Carolina at Chapel Hill, Class of 2014 chadams@redhat.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 10:35:47 AM, akcrisp (notifications@github.com) wrote:

Reading this exchange - https://groups.google.com/forum/#!topic/awx-project/LcyEosimwZg

If I read that correctly still implies it requires an initial password to do programmatically ? Can someone confirm if i am missing the point drastically ?? @wenottingham @matburt @rooftopcellist

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ansible/awx/issues/21#issuecomment-391117859, or mute the thread https://github.com/notifications/unsubscribe-auth/ALKCzI6ZAW9zToMXEX13nCFEEH8VFv8Qks5t1GuIgaJpZM4PO5zC .

akcrisp commented 6 years ago

Thanks Christian - really useful info - I think there is a need for more detailed docs explaining this.

Andy

Sent from my iPhone

On 22 May 2018, at 21:14, Christian Adams notifications@github.com wrote:

Hi Andy,

The full name in the UI is Resource owner password-based grant type. There is no need for a redirect_uri to be specified for this grant type.

You will have to create tokens for the application you have made, either through the browsable API, or with a curl. For example, if you go to http:///api/v2/tokens/ and post the following JSON, you will see a token appear in the UI.

{ "description": "My First App Token", "application": 1, <<< or the id of your application "scope": "write" }

When you create an application, it does not automatically create a token. The UI does not currently support Token creation. This will work with user populated into awx using ldap as well. The token will assume all of the permissions that user has if given the write scope.

Thanks, Christian

Christian M. Adams University of North Carolina at Chapel Hill, Class of 2014 BA Chemistry, BM Music Performance | Sound Engineer at Continuum Audio rooftopcellist@gmail.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 3:48:25 PM, akcrisp (notifications@github.com) wrote:

Ok and when setting up the application in the awx gui what grant type do I use as there isn’t one called “password” ? This is 1.0.6.8 build. If I create it in the awx gui I assumed the tokens would then appear under the token tab ? However there was nothing when I created it (implicit grant type I tried).

Is the redirect_uris always the same ( http://localhost:8013/api/v2/applications/) ?

And by created user in awx I assume this works if the account in question is actually in AD and awx is looking the users up via ldap as configured in gui ?

Thanks

Andy

Sent from my iPhone

On 22 May 2018, at 20:15, Christian Adams notifications@github.com wrote:

Hi Akcrisp,

Like you mentioned, the authorization flow depends on your grant type, but you will need to have already created a user in AWX to acquire a token no matter what grant type you use. For programmatically creating an OAuth2 token you will want to use a “password” grant type. Here is an example curl to make a “password” grant application:

curl -ku user:password -H "Content-Type: application/json" -d '{"name": “Akcrisp Application", "client_type": "confidential", "authorization_grant_type": "password", "organization": 1}' -X POST http://localhost:8013/api/v2/applications/

This will return a client_id an client_secret for the newly created “password” grant type application. You can use a curl like this to acquire a token for that application:

curl -X POST \ -d "grant_type=password&username=&password=&scope=read" \ -u “:" \ http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).

Thanks, Christian

Christian M. Adams Associate Software Engineer at Ansible - Red Hat University of North Carolina at Chapel Hill, Class of 2014 chadams@redhat.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 10:35:47 AM, akcrisp (notifications@github.com) wrote:

Reading this exchange - https://groups.google.com/forum/#!topic/awx-project/LcyEosimwZg

If I read that correctly still implies it requires an initial password to do programmatically ? Can someone confirm if i am missing the point drastically ?? @wenottingham @matburt @rooftopcellist

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ansible/awx/issues/21#issuecomment-391117859, or mute the thread https://github.com/notifications/unsubscribe-auth/ALKCzI6ZAW9zToMXEX13nCFEEH8VFv8Qks5t1GuIgaJpZM4PO5zC . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

akcrisp commented 6 years ago

One more question - can we also permission access via teams and not just users ? If not then I will need to raise an rfe

Andy

Sent from my iPhone

On 22 May 2018, at 21:14, Christian Adams notifications@github.com wrote:

Hi Andy,

The full name in the UI is Resource owner password-based grant type. There is no need for a redirect_uri to be specified for this grant type.

You will have to create tokens for the application you have made, either through the browsable API, or with a curl. For example, if you go to http:///api/v2/tokens/ and post the following JSON, you will see a token appear in the UI.

{ "description": "My First App Token", "application": 1, <<< or the id of your application "scope": "write" }

When you create an application, it does not automatically create a token. The UI does not currently support Token creation. This will work with user populated into awx using ldap as well. The token will assume all of the permissions that user has if given the write scope.

Thanks, Christian

Christian M. Adams University of North Carolina at Chapel Hill, Class of 2014 BA Chemistry, BM Music Performance | Sound Engineer at Continuum Audio rooftopcellist@gmail.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 3:48:25 PM, akcrisp (notifications@github.com) wrote:

Ok and when setting up the application in the awx gui what grant type do I use as there isn’t one called “password” ? This is 1.0.6.8 build. If I create it in the awx gui I assumed the tokens would then appear under the token tab ? However there was nothing when I created it (implicit grant type I tried).

Is the redirect_uris always the same ( http://localhost:8013/api/v2/applications/) ?

And by created user in awx I assume this works if the account in question is actually in AD and awx is looking the users up via ldap as configured in gui ?

Thanks

Andy

Sent from my iPhone

On 22 May 2018, at 20:15, Christian Adams notifications@github.com wrote:

Hi Akcrisp,

Like you mentioned, the authorization flow depends on your grant type, but you will need to have already created a user in AWX to acquire a token no matter what grant type you use. For programmatically creating an OAuth2 token you will want to use a “password” grant type. Here is an example curl to make a “password” grant application:

curl -ku user:password -H "Content-Type: application/json" -d '{"name": “Akcrisp Application", "client_type": "confidential", "authorization_grant_type": "password", "organization": 1}' -X POST http://localhost:8013/api/v2/applications/

This will return a client_id an client_secret for the newly created “password” grant type application. You can use a curl like this to acquire a token for that application:

curl -X POST \ -d "grant_type=password&username=&password=&scope=read" \ -u “:" \ http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).

Thanks, Christian

Christian M. Adams Associate Software Engineer at Ansible - Red Hat University of North Carolina at Chapel Hill, Class of 2014 chadams@redhat.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 10:35:47 AM, akcrisp (notifications@github.com) wrote:

Reading this exchange - https://groups.google.com/forum/#!topic/awx-project/LcyEosimwZg

If I read that correctly still implies it requires an initial password to do programmatically ? Can someone confirm if i am missing the point drastically ?? @wenottingham @matburt @rooftopcellist

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ansible/awx/issues/21#issuecomment-391117859, or mute the thread https://github.com/notifications/unsubscribe-auth/ALKCzI6ZAW9zToMXEX13nCFEEH8VFv8Qks5t1GuIgaJpZM4PO5zC . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

akcrisp commented 6 years ago

Hi Christian,

I have just re read your email where you talk receiving a token back ie -

This will return a client_id an client_secret for the newly created “password” grant type application. You can use a curl like this to acquire a token for that application:

curl -X POST \ -d "grant_type=password&username=&password=&scope=read" \ -u “:" \ http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).

Now looking at the above it appears to me in order to get the token back I am still having to specify a username and password ? So I am trying to avoid having to manage passwords - looking at this I think your checking the user authorisation ie login first to get token - correct ? In which case I don’t see how this differs from previous version of requiring a username and password to get access to the api (which is why we raised the rfe against Redhat in first place)

What about supporting ssl public / private keys to allow authorisation?

Andy

Sent from my iPhone

On 22 May 2018, at 21:14, Christian Adams notifications@github.com wrote:

Hi Andy,

The full name in the UI is Resource owner password-based grant type. There is no need for a redirect_uri to be specified for this grant type.

You will have to create tokens for the application you have made, either through the browsable API, or with a curl. For example, if you go to http:///api/v2/tokens/ and post the following JSON, you will see a token appear in the UI.

{ "description": "My First App Token", "application": 1, <<< or the id of your application "scope": "write" }

When you create an application, it does not automatically create a token. The UI does not currently support Token creation. This will work with user populated into awx using ldap as well. The token will assume all of the permissions that user has if given the write scope.

Thanks, Christian

Christian M. Adams University of North Carolina at Chapel Hill, Class of 2014 BA Chemistry, BM Music Performance | Sound Engineer at Continuum Audio rooftopcellist@gmail.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 3:48:25 PM, akcrisp (notifications@github.com) wrote:

Ok and when setting up the application in the awx gui what grant type do I use as there isn’t one called “password” ? This is 1.0.6.8 build. If I create it in the awx gui I assumed the tokens would then appear under the token tab ? However there was nothing when I created it (implicit grant type I tried).

Is the redirect_uris always the same ( http://localhost:8013/api/v2/applications/) ?

And by created user in awx I assume this works if the account in question is actually in AD and awx is looking the users up via ldap as configured in gui ?

Thanks

Andy

Sent from my iPhone

On 22 May 2018, at 20:15, Christian Adams notifications@github.com wrote:

Hi Akcrisp,

Like you mentioned, the authorization flow depends on your grant type, but you will need to have already created a user in AWX to acquire a token no matter what grant type you use. For programmatically creating an OAuth2 token you will want to use a “password” grant type. Here is an example curl to make a “password” grant application:

curl -ku user:password -H "Content-Type: application/json" -d '{"name": “Akcrisp Application", "client_type": "confidential", "authorization_grant_type": "password", "organization": 1}' -X POST http://localhost:8013/api/v2/applications/

This will return a client_id an client_secret for the newly created “password” grant type application. You can use a curl like this to acquire a token for that application:

curl -X POST \ -d "grant_type=password&username=&password=&scope=read" \ -u “:" \ http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).

Thanks, Christian

Christian M. Adams Associate Software Engineer at Ansible - Red Hat University of North Carolina at Chapel Hill, Class of 2014 chadams@redhat.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 10:35:47 AM, akcrisp (notifications@github.com) wrote:

Reading this exchange - https://groups.google.com/forum/#!topic/awx-project/LcyEosimwZg

If I read that correctly still implies it requires an initial password to do programmatically ? Can someone confirm if i am missing the point drastically ?? @wenottingham @matburt @rooftopcellist

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ansible/awx/issues/21#issuecomment-391117859, or mute the thread https://github.com/notifications/unsubscribe-auth/ALKCzI6ZAW9zToMXEX13nCFEEH8VFv8Qks5t1GuIgaJpZM4PO5zC . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

rooftopcellist commented 6 years ago

The benefit of using OAuth2 tokens is that after the token is initially acquired (which requires a username/password), you can discard the username/password and used the token to authenticate from that point forward. For example:

curl -H "Authorization: Bearer " https://localhost:8043/api/v2/hosts/

Thanks, Christian

Christian M. Adams University of North Carolina at Chapel Hill, Class of 2014 BA Chemistry, BM Music Performance | Sound Engineer at Continuum Audio rooftopcellist@gmail.com | (919) 218-5080 | GitHub: rooftopcellist

On May 23, 2018 at 4:09:32 AM, akcrisp (notifications@github.com) wrote:

Hi Christian,

I have just re read your email where you talk receiving a token back ie -

This will return a client_id an client_secret for the newly created “password” grant type application. You can use a curl like this to acquire a token for that application:

curl -X POST \ -d "grant_type=password&username=&password=&scope=read" \ -u “:" \ http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).

Now looking at the above it appears to me in order to get the token back I am still having to specify a username and password ? So I am trying to avoid having to manage passwords - looking at this I think your checking the user authorisation ie login first to get token - correct ? In which case I don’t see how this differs from previous version of requiring a username and password to get access to the api (which is why we raised the rfe against Redhat in first place)

What about supporting ssl public / private keys to allow authorisation?

Andy

Sent from my iPhone

On 22 May 2018, at 21:14, Christian Adams notifications@github.com wrote:

Hi Andy,

The full name in the UI is Resource owner password-based grant type. There is no need for a redirect_uri to be specified for this grant type.

You will have to create tokens for the application you have made, either through the browsable API, or with a curl. For example, if you go to http:///api/v2/tokens/ and post the following JSON, you will see a token appear in the UI.

{ "description": "My First App Token", "application": 1, <<< or the id of your application "scope": "write" }

When you create an application, it does not automatically create a token. The UI does not currently support Token creation. This will work with user populated into awx using ldap as well. The token will assume all of the permissions that user has if given the write scope.

Thanks, Christian

Christian M. Adams University of North Carolina at Chapel Hill, Class of 2014 BA Chemistry, BM Music Performance | Sound Engineer at Continuum Audio rooftopcellist@gmail.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 3:48:25 PM, akcrisp (notifications@github.com) wrote:

Ok and when setting up the application in the awx gui what grant type do I use as there isn’t one called “password” ? This is 1.0.6.8 build. If I create it in the awx gui I assumed the tokens would then appear under the token tab ? However there was nothing when I created it (implicit grant type I tried).

Is the redirect_uris always the same ( http://localhost:8013/api/v2/applications/) ?

And by created user in awx I assume this works if the account in question is actually in AD and awx is looking the users up via ldap as configured in gui ?

Thanks

Andy

Sent from my iPhone

On 22 May 2018, at 20:15, Christian Adams notifications@github.com wrote:

Hi Akcrisp,

Like you mentioned, the authorization flow depends on your grant type, but you will need to have already created a user in AWX to acquire a token no matter what grant type you use. For programmatically creating an OAuth2 token you will want to use a “password” grant type. Here is an example curl to make a “password” grant application:

curl -ku user:password -H "Content-Type: application/json" -d '{"name": “Akcrisp Application", "client_type": "confidential", "authorization_grant_type": "password", "organization": 1}' -X POST http://localhost:8013/api/v2/applications/

This will return a client_id an client_secret for the newly created “password” grant type application. You can use a curl like this to acquire a token for that application:

curl -X POST \ -d "grant_type=password&username=&password=&scope=read" \ -u “:" \ http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).

Thanks, Christian

Christian M. Adams Associate Software Engineer at Ansible - Red Hat University of North Carolina at Chapel Hill, Class of 2014 chadams@redhat.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 10:35:47 AM, akcrisp (notifications@github.com) wrote:

Reading this exchange - https://groups.google.com/forum/#!topic/awx-project/LcyEosimwZg

If I read that correctly still implies it requires an initial password to do programmatically ? Can someone confirm if i am missing the point drastically ?? @wenottingham @matburt @rooftopcellist

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ansible/awx/issues/21#issuecomment-391117859, or mute the thread < https://github.com/notifications/unsubscribe-auth/ALKCzI6ZAW9zToMXEX13nCFEEH8VFv8Qks5t1GuIgaJpZM4PO5zC

. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ansible/awx/issues/21#issuecomment-391259265, or mute the thread https://github.com/notifications/unsubscribe-auth/ALKCzCviWf1t3uRGBmjOr9S09RkRHYZXks5t1Rk8gaJpZM4PO5zC .

akcrisp commented 6 years ago

So i think I need to refer back to red hat because when we raised the rfe against Redhat originally (was using ansible tower then) the point was passwords made automation painful. What appears to have been done is move that requirement not get rid of it. I assumed you guys would as an option be looking to use ssl public / private keys with oauth2 as alternative. I will now raise that as an rfe on GitHub

Thanks for the info

Andy

Sent from my iPhone

On 23 May 2018, at 14:41, Christian Adams notifications@github.com wrote:

The benefit of using OAuth2 tokens is that after the token is initially acquired (which requires a username/password), you can discard the username/password and used the token to authenticate from that point forward. For example:

curl -H "Authorization: Bearer " https://localhost:8043/api/v2/hosts/

Thanks, Christian

Christian M. Adams University of North Carolina at Chapel Hill, Class of 2014 BA Chemistry, BM Music Performance | Sound Engineer at Continuum Audio rooftopcellist@gmail.com | (919) 218-5080 | GitHub: rooftopcellist

On May 23, 2018 at 4:09:32 AM, akcrisp (notifications@github.com) wrote:

Hi Christian,

I have just re read your email where you talk receiving a token back ie -

This will return a client_id an client_secret for the newly created “password” grant type application. You can use a curl like this to acquire a token for that application:

curl -X POST \ -d "grant_type=password&username=&password=&scope=read" \ -u “:" \ http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).

Now looking at the above it appears to me in order to get the token back I am still having to specify a username and password ? So I am trying to avoid having to manage passwords - looking at this I think your checking the user authorisation ie login first to get token - correct ? In which case I don’t see how this differs from previous version of requiring a username and password to get access to the api (which is why we raised the rfe against Redhat in first place)

What about supporting ssl public / private keys to allow authorisation?

Andy

Sent from my iPhone

On 22 May 2018, at 21:14, Christian Adams notifications@github.com wrote:

Hi Andy,

The full name in the UI is Resource owner password-based grant type. There is no need for a redirect_uri to be specified for this grant type.

You will have to create tokens for the application you have made, either through the browsable API, or with a curl. For example, if you go to http:///api/v2/tokens/ and post the following JSON, you will see a token appear in the UI.

{ "description": "My First App Token", "application": 1, <<< or the id of your application "scope": "write" }

When you create an application, it does not automatically create a token. The UI does not currently support Token creation. This will work with user populated into awx using ldap as well. The token will assume all of the permissions that user has if given the write scope.

Thanks, Christian

Christian M. Adams University of North Carolina at Chapel Hill, Class of 2014 BA Chemistry, BM Music Performance | Sound Engineer at Continuum Audio rooftopcellist@gmail.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 3:48:25 PM, akcrisp (notifications@github.com) wrote:

Ok and when setting up the application in the awx gui what grant type do I use as there isn’t one called “password” ? This is 1.0.6.8 build. If I create it in the awx gui I assumed the tokens would then appear under the token tab ? However there was nothing when I created it (implicit grant type I tried).

Is the redirect_uris always the same ( http://localhost:8013/api/v2/applications/) ?

And by created user in awx I assume this works if the account in question is actually in AD and awx is looking the users up via ldap as configured in gui ?

Thanks

Andy

Sent from my iPhone

On 22 May 2018, at 20:15, Christian Adams notifications@github.com wrote:

Hi Akcrisp,

Like you mentioned, the authorization flow depends on your grant type, but you will need to have already created a user in AWX to acquire a token no matter what grant type you use. For programmatically creating an OAuth2 token you will want to use a “password” grant type. Here is an example curl to make a “password” grant application:

curl -ku user:password -H "Content-Type: application/json" -d '{"name": “Akcrisp Application", "client_type": "confidential", "authorization_grant_type": "password", "organization": 1}' -X POST http://localhost:8013/api/v2/applications/

This will return a client_id an client_secret for the newly created “password” grant type application. You can use a curl like this to acquire a token for that application:

curl -X POST \ -d "grant_type=password&username=&password=&scope=read" \ -u “:" \ http://localhost:8013/api/o/token/ -i

With this method, you will directly receive a token back — no need to have a user logged in (implicit), and no need to have a logged in user actually click authorize (authorization grant flow).

Thanks, Christian

Christian M. Adams Associate Software Engineer at Ansible - Red Hat University of North Carolina at Chapel Hill, Class of 2014 chadams@redhat.com | (919) 218-5080 | GitHub: rooftopcellist

On May 22, 2018 at 10:35:47 AM, akcrisp (notifications@github.com) wrote:

Reading this exchange - https://groups.google.com/forum/#!topic/awx-project/LcyEosimwZg

If I read that correctly still implies it requires an initial password to do programmatically ? Can someone confirm if i am missing the point drastically ?? @wenottingham @matburt @rooftopcellist

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ansible/awx/issues/21#issuecomment-391117859, or mute the thread < https://github.com/notifications/unsubscribe-auth/ALKCzI6ZAW9zToMXEX13nCFEEH8VFv8Qks5t1GuIgaJpZM4PO5zC

. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ansible/awx/issues/21#issuecomment-391259265, or mute the thread https://github.com/notifications/unsubscribe-auth/ALKCzCviWf1t3uRGBmjOr9S09RkRHYZXks5t1Rk8gaJpZM4PO5zC . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

dnc92301 commented 6 years ago

It seems "Application" is only visible to "Systems Administrator." So an Organization's Admin does NOT have the ability to create it's own Application and assign Token. I see generated token - "expires_in": 31536000000 which is basically set to "unlimited." If you covert to years this is 1000! This is fine - if you don't tell the auditors :)

We want to make this as 'self service' as possible so by limiting this privilege of defining Application to System Administer might be counter-productive. Is it by design? An System Administrator will pre-create all Tokens for specific app(s). The Token is set to never-expired - making it a one-time setup?

Moreover, I don't see the ability to "delete" Tokens. I see all the available tokens requested using "client_id" + "client_secret".

I definitely see the advantage of using OAuth2 as opposed to be sending my credentials in clear-txt. However, it is not as user friendly as I would expect it to be.

Thanks

jangsutsr commented 6 years ago

@dnc92301 Hey, think I can partly answer your questions:

1) The 1000-years-expiration-time is the default value. You may find it configurable using 'Tower Configuration' feature: http://docs.ansible.com/ansible-tower/latest/html/administration/configure_tower_in_tower.html. If not, open an issue so developers know they missed that. 2) Yes, it is by design that only system admin holds write access to applications. You should open an issue to propose expanding the access to org admins if that is helpful. 3) If I remember correctly, an OAuth token is deleted when you refresh it or when it expires. If you do not see a 'delete' button in API browser, though, then explicit token delete endpoint is most likely not implemented. Again, open an issue to propose adding the endpoint if that is helpful.

Hope that helps!

dnc92301 commented 6 years ago

Aaron - Thanks much for the quick response! I recall in version 1.0.5 there's a option within Template for toggling between Virtual Environment. It seems this feature/button is NOT available in 1.0.6. Has this feature been removed? Or it's somehow missing in this specific version/tag - 1.0.6.11? This is important feature to have for managing legacy environment which may not play well with the latest Ansible core, or pywinrm, etc.

Thanks again.

jangsutsr commented 6 years ago

@dnc92301 My pleasure. I am a contributor who worked on OAuth system before, but I do not have enough domain knowledge to answer your question on venv control. I suggest opening a separate issue so members of Ansible familiar with that part of AWX will notice it and help you out.

Cheers

ryanpetrello commented 6 years ago

@dnc92301,

I recall in version 1.0.5 there's a option within Template for toggling between Virtual Environment. It seems this feature/button is NOT available in 1.0.6. Has this feature been removed? Or it's somehow missing in this specific version/tag - 1.0.6.11?

The dropdown will only appear if you've actually added one or more custom virtualenvs to /var/lib/awx/venv/. If you have done this, and you're still not seeing the Virtual Environment selection when editing a Job Template, please file a bug.

rooftopcellist commented 6 years ago

@dnc92301 In regards to your OAuth2 questions:

The expiration time is configurable through the API at /api/v2/settings/authentication/, even though it is not yet exposed in the UI.

Org Admins do have the ability to read/write applications for their org, there is currently a bug where the button does not show on the left when org admins are logged in. As a work around, you can currently just navigate directly to: https:///#/applications?application_search=page_size:20;order_by:name`.

You can delete tokens in the browseable API by going to any detail page for a token and clicking the DELETE button, or through the UI by clicking the trash can symbol next to the token at the User -- Tokens tab.

akcrisp commented 6 years ago

@rooftopcellist I have been playing with applications and tokens - I can create both no problem at all either via curl or in the UI, (once application is created, you can create a token under users pointing back to the application).

Couple of questions -

  1. using curl when creating tokens I don't appear to be able to add descriptions - I've tried various forms of curl command and although it returns a bearer token - when i look in the api the description is always empty - example curl here -

curl -X POST --data "grant_type=password&username=&password=&scope=write&description=test" -u ": https:///api/o/token/ -i

I can set the scope no problem at all. Creating it in the UI I can set the description.

  1. when creating applications can you see a requirement / use to ever set the redirect uris ? Given applications are tied to an organization, and we have per app organizations and as you say it in herits the permissions of the user creating the token, I am pondering whether there is a requirement to restrict it further.

  2. Is there any plans to allow an admin / or org admin be able to create a token of other users and therefore restrict who can actually create tokens. We would prefer to be able to control this.

Andy

rooftopcellist commented 6 years ago

@akcrisp Thanks for the feedback! I'm sorry I didn't see this earlier.

  1. Unfortunately, the underlying library that the api/o/ endpoints are built on does not have the description field natively, that is something we added afterwards, so they don't have any handling for that. One way around this, is you could issue tokens through a POST to /api/v2/tokens/ or any of the other token endpoints, descriptions will work there.
  2. The redirect_uri is required in the RFC (https://tools.ietf.org/html/rfc6749)
  3. This is in the plans: https://github.com/ansible/awx/issues/1653
akcrisp commented 6 years ago

@rooftopcellist can you tell me if the oauth2 implementation supports a 3rd party token end point ?

rooftopcellist commented 6 years ago

@akcrisp it sounds like you are referring to a separate Authorization Server -- https://django-oauth-toolkit.readthedocs.io/en/latest/resource_server.html. To be clear, this is not yet implemented in AWX.