[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Is there any administration API to manage the app/cartridges as system admin



There is an integration scenario that might work better for you using the X-Impersonate header.  Passing the header lets a single user account manage child accounts as the child user directly.  A few caveats - impersonate requires the user to be created in mongo by the impersonate call, so if the user has logged in first to the API you'll have to fix up the user with oo-admin-ctl-user.  See https://github.com/openshift/origin-server/blob/master/controller/lib/openshift/controller/authentication.rb#L240

for more on how impersonate works.  You can mark an account as being able to impersonate with:

  oo-admin-ctl-user --allowsubaccounts true -l <adminacct>

The only other form of true impersonation is through tokens, and longer term that will be the recommended way to give one user access to your account temporarily.

In general we recommend all API consumers to use authorization tokens for a few reasons.  

1) it means that other clients can centrally revoke access to other sessions in a consistent way

2) tokens can be limited in rights - for instance, a token that only grants read access, or a token that allows access only to a single app.

3) it simplifies clients and is higher performance - the token is stored in the Openshift mongo db and is faster to retrieve, vs auth calls to an external service which must be done on every request.

4) a token can be changed more easily than a password



On Jun 23, 2013, at 6:58 AM, XuQing Tan <missedone gmail com> wrote:

thanks, all

the option #2, hackish way, works for me. 
On the broker, set the the header 'X-Remote-User' to manage domain/app/cartridges on behalf of others.
in regards to the auth token, I'm OK with password since I don't see how to configure the auth token be valid for ever (won't expired).

however, I will re-evaluate the auth token expiration later since I have to put my LDAP password in a config file which is not good

  Thanks & Best Regards!

                  ///
                 (. .)
  --------ooO--(_)--Ooo--------
  |           Nick Tan           |
  ------------------------------------


On Fri, Jun 21, 2013 at 11:25 PM, Clayton Coleman <ccoleman redhat com> wrote:
See the following in broker.conf:


# Set the default and maximum expiration for authorization tokens by
# type.  Comma delimited list of expiration pairs, where the key
# corresponds the canonical form of a scope, and the value corresponds
# to one or two time durations.  The time durations may be specified in
# standard ruby syntax (<number>.days) are converted to seconds.  If two
# times are specified, the first is the default value and the second is
# the maximum duration the token may exist for. The key '*' will apply
# to all other scopes.
#
# Recognized scopes:
#
#   userinfo - access to only information about the current user
#   read     - read-only access to the REST API
#   session  - full access as the user
#
# Examples:
#
#   # All tokens, regardless of type, expire in 1 month and default to
#   # 1 month in duration.
#   AUTH_SCOPE_TIMEOUTS="*=1.months"
#
#   # All tokens, regardless of type, expire in 1 month and default to
#   # 1 week in duration.
#   AUTH_SCOPE_TIMEOUTS="*=1.week|1.months"
#
#   # The read scope expires in 1 day, all other tokens expire in one
#   # week.
#   AUTH_SCOPE_TIMEOUTS="read=1.month, *=1.week"
#
# The value may be any valid Ruby _expression_ that evaluates to a number.
#
AUTH_SCOPE_TIMEOUTS="session=1.days|7.days, *=1.months|6.months"


If you want session scope to last for a year, do:

  AUTH_SCOPE_TIMEOUTS="session=1.year, *=1.months|6.months"

or 2 years

  AUTH_SCOPE_TIMEOUTS="session=2.years, *=1.months|6.months"

or all tokens last 2 years

  AUTH_SCOPE_TIMEOUTS="*=2.years"

----- Original Message -----
> another question is, how can I tune the expiration? to
> configure expires_in? can I configure it as infinite (won't expire)?
>
> thanks
>
>   Thanks & Best Regards!
>
>                   ///
>                  (. .)
>   --------ooO--(_)--Ooo--------
>   |           Nick Tan           |
>   ------------------------------------
>
>
> On Fri, Jun 21, 2013 at 9:03 AM, XuQing Tan <missedone gmail com> wrote:
>
> > thanks for your reply
> >
> > before read the code to understand the logic of remote-user auth, here i
> > have one question:
> > if i hack to use the auth proxy, aka, remote-user, will the basic auth
> > still applied? i mean if i hack to put my admin token in the remote-user,
> > if the user's basic auth not applied, how can i know it's a valid user?
> >
> >
> >   Thanks & Best Regards!
> >
> >                   ///
> >                  (. .)
> >   --------ooO--(_)--Ooo--------
> >   |           Nick Tan           |
> >   ------------------------------------
> >
> >
> > On Wed, Jun 19, 2013 at 9:32 PM, Clayton Coleman
> > <ccoleman redhat com>wrote:
> >
> >> That's tunable to admins - can set an arbitrary expiration in OSE or
> >> origin
> >>
> >> On Jun 19, 2013, at 8:35 AM, Andy Goldstein <agoldste redhat com> wrote:
> >>
> >> >
> >> > On Jun 19, 2013, at 4:36 AM, Brenton Leanhardt wrote:
> >> >
> >> >> +++ XuQing Tan [19/06/13 16:26 +0800]:
> >> >>> hi, Krishna
> >> >>>
> >> >>> i'm working on a PoC to integrate openshift origin with our existing
> >> system
> >> >>> (it's kind of a ticket system, that user can request to create app
> >> etc).
> >> >>>
> >> >>> as the system admin, now i want to programmatically create the app on
> >> >>> openshift for the user.
> >> >>>
> >> >>> note that, as system admin, i don't have the user's credentials (they
> >> are
> >> >>> in LDAP, i don't have access). but for now, i found that openshift
> >> rest API
> >> >>> request the user's credentials to create the app.
> >> >>>
> >> >>> so, have can I use my system admin account, to create the app for
> >> that user?
> >> >>
> >> >> I'm betting the proper way to do this would be to somehow generate an
> >> >> authorization token that would give all you to create applications on
> >> >> behalf of another user.
> >> >
> >> > Our tokens expire after 24 hours, right? That could be a bit of a
> >> wrinkle if you go that routeā€¦ ?
> >> >
> >> >>
> >> >> A hackish way to do this is to use the remote-user authentication
> >> >> plugin.  All requests coming in to the SSL-termination proxy require
> >> >> authentication.  However if you have access to localhost:8080 on the
> >> >> Broker machine you can set the REMOTE_USER header to whatever user you
> >> >> wish.  Then you could create applications using curl or anything that
> >> >> can generate the appropriate request.
> >> >>
> >> >>>
> >> >>> thanks:)
> >> >>>
> >> >>> Thanks & Best Regards!
> >> >>>
> >> >>>                ///
> >> >>>               (. .)
> >> >>> --------ooO--(_)--Ooo--------
> >> >>> |           Nick Tan           |
> >> >>> ------------------------------------
> >> >>
> >> >>> _______________________________________________
> >> >>> dev mailing list
> >> >>> dev lists openshift redhat com
> >> >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >> >>
> >> >> _______________________________________________
> >> >> dev mailing list
> >> >> dev lists openshift redhat com
> >> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >> >
> >> >
> >> > _______________________________________________
> >> > dev mailing list
> >> > dev lists openshift redhat com
> >> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >>
> >> _______________________________________________
> >> dev mailing list
> >> dev lists openshift redhat com
> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> >>
> >
> >
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]