organism access/group membership for newly created Remote User accounts.

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

organism access/group membership for newly created Remote User accounts.

t.r.stickland@sanger.ac.uk
Now I have Remote User Authentication working in Apollo, I have a new
problem regarding organism access.

Until now, I have used the API to create user accounts, and granted
access to organisms (generally by adding them to a pre-existing group)
right after creating the account.  The creation of the account and
granting of access rights isn't synchronous, but that's OK as I perform
these actions and then give the account details to the end user afterwards.

The issue with Remote User Authentication is that a new user account is
created automatically the first time an end user logs in.  As this is an
event triggered by the end user, it results in them having an Apollo
session before I have the chance to grant organism access.   So they are
logged in but with no access to anything :(

I can give the user access using the API, but I don't have the chance to
do this until after their Apollo session starts --  so their first
session will always result in them being greeted with a dialog telling
them they have no permission to see anything.    All I can do is create
some process whereby they come back later on after I have "activated"
the account.  Even if I can automate this so it occurs within minutes,
or even within a few seconds, it will still be too late to stop users
experiencing an initial session with no access.

A perfect solution would be to have an event that was triggered in
between the creation of a new Remote User account, and the initiation of
their session.  I don't think Apollo has any such hook, but hey, I
thought I'd mention it in case Nathan is feeling particularly industrious ;)

Another solution be to have some sort of default level of access that
was granted to all authorized users -- either an "any authorized user"
group into which all users were placed when they log in, or simply the
ability to configure default levels of organism access.    I've read
through the Apollo documentation on organism access/group membership,
and I don't think this is supported?

Have I missed something?  (Hopefully!)    Or will I have to grant
organism/group access to user accounts as a separate action, at some
point after they are created?

thanks

Tim





--
 The Wellcome Sanger Institute is operated by Genome Research
 Limited, a charity registered in England with number 1021457 and a
 company registered in England with number 2742969, whose registered
 office is 215 Euston Road, London, NW1 2BE.

--
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

Reply | Threaded
Open this post in threaded view
|

Re: organism access/group membership for newly created Remote User accounts. [EXT]

t.r.stickland@sanger.ac.uk
A nice thought, but unfortunately I don't know who the users will be.  The notion is to trust an identity provider, and allow a certain level of access to everyone who can log in via that provider.

For the benefit of anyone reading this, for who that may be an answer:  bear in mind that users who arrive via OpenIDC authentication have a user ID of the form [hidden email].     It might be possible to retrieve user profile information from their identity provider afterwards, and that would give you their identity IRL, but this is an operation that has to be done after they log in for the first time -- which brings us back to where we started :)

(Other forms of Remote User authentication may of course give you an email address as user ID, in which case you're off to a good start.)

tim



On 04/11/2019 15:47, Helena Rasche wrote:
Since it sounds like you might know your users ahead of time, maybe if you know their email address, you could pre-create the account + grant access to the correct organisms?

logging in with remote user afterwards should just overwrite first/last name associated with that account.


But I guess in general I have the same problem, "drive by users" who might want to see what it looks like can't see anything and it would be nice if they could add least have viewer permissions on any organism marked "public", so we could mark a demo organism public and everyone could at least see it.

On 04.11.19 15:03, Tim Stickland wrote:
Now I have Remote User Authentication working in Apollo, I have a new problem regarding organism access.

Until now, I have used the API to create user accounts, and granted access to organisms (generally by adding them to a pre-existing group) right after creating the account.  The creation of the account and granting of access rights isn't synchronous, but that's OK as I perform these actions and then give the account details to the end user afterwards.

The issue with Remote User Authentication is that a new user account is created automatically the first time an end user logs in.  As this is an event triggered by the end user, it results in them having an Apollo session before I have the chance to grant organism access.   So they are logged in but with no access to anything :(

I can give the user access using the API, but I don't have the chance to do this until after their Apollo session starts --  so their first session will always result in them being greeted with a dialog telling them they have no permission to see anything. All I can do is create some process whereby they come back later on after I have "activated" the account.  Even if I can automate this so it occurs within minutes, or even within a few seconds, it will still be too late to stop users experiencing an initial session with no access.

A perfect solution would be to have an event that was triggered in between the creation of a new Remote User account, and the initiation of their session.  I don't think Apollo has any such hook, but hey, I thought I'd mention it in case Nathan is feeling particularly industrious ;)

Another solution be to have some sort of default level of access that was granted to all authorized users -- either an "any authorized user" group into which all users were placed when they log in, or simply the ability to configure default levels of organism access.    I've read through the Apollo documentation on organism access/group membership, and I don't think this is supported?

Have I missed something?  (Hopefully!)    Or will I have to grant organism/group access to user accounts as a separate action, at some point after they are created?

thanks

Tim







-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

--
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: organism access/group membership for newly created Remote User accounts. [EXT]

nathandunn

Tim,

Would allowing a specified user group to be added by default upon registration work? 


Conversely, maybe you want the default group to be dependent on the user_name (which might include ‘*').

Nathan


On Nov 4, 2019, at 8:39 AM, Tim Stickland <[hidden email]> wrote:

A nice thought, but unfortunately I don't know who the users will be.  The notion is to trust an identity provider, and allow a certain level of access to everyone who can log in via that provider.

For the benefit of anyone reading this, for who that may be an answer:  bear in mind that users who arrive via OpenIDC authentication have a user ID of the form [hidden email].     It might be possible to retrieve user profile information from their identity provider afterwards, and that would give you their identity IRL, but this is an operation that has to be done after they log in for the first time -- which brings us back to where we started :)

(Other forms of Remote User authentication may of course give you an email address as user ID, in which case you're off to a good start.)

tim



On 04/11/2019 15:47, Helena Rasche wrote:
Since it sounds like you might know your users ahead of time, maybe if you know their email address, you could pre-create the account + grant access to the correct organisms?

logging in with remote user afterwards should just overwrite first/last name associated with that account.


But I guess in general I have the same problem, "drive by users" who might want to see what it looks like can't see anything and it would be nice if they could add least have viewer permissions on any organism marked "public", so we could mark a demo organism public and everyone could at least see it.

On 04.11.19 15:03, Tim Stickland wrote:
Now I have Remote User Authentication working in Apollo, I have a new problem regarding organism access.

Until now, I have used the API to create user accounts, and granted access to organisms (generally by adding them to a pre-existing group) right after creating the account.  The creation of the account and granting of access rights isn't synchronous, but that's OK as I perform these actions and then give the account details to the end user afterwards.

The issue with Remote User Authentication is that a new user account is created automatically the first time an end user logs in.  As this is an event triggered by the end user, it results in them having an Apollo session before I have the chance to grant organism access.   So they are logged in but with no access to anything :(

I can give the user access using the API, but I don't have the chance to do this until after their Apollo session starts --  so their first session will always result in them being greeted with a dialog telling them they have no permission to see anything. All I can do is create some process whereby they come back later on after I have "activated" the account.  Even if I can automate this so it occurs within minutes, or even within a few seconds, it will still be too late to stop users experiencing an initial session with no access.

A perfect solution would be to have an event that was triggered in between the creation of a new Remote User account, and the initiation of their session.  I don't think Apollo has any such hook, but hey, I thought I'd mention it in case Nathan is feeling particularly industrious ;)

Another solution be to have some sort of default level of access that was granted to all authorized users -- either an "any authorized user" group into which all users were placed when they log in, or simply the ability to configure default levels of organism access.    I've read through the Apollo documentation on organism access/group membership, and I don't think this is supported?

Have I missed something?  (Hopefully!)    Or will I have to grant organism/group access to user accounts as a separate action, at some point after they are created?

thanks

Tim







-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

--
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: organism access/group membership for newly created Remote User accounts. [EXT]

t.r.stickland@sanger.ac.uk
what you suggest in #2302 would be fine for me, thanks

The option to allocated membership of group(s) depending on user ID would be very nice to have, in theory, but I guess it would be a lot more work -- and I can't honestly say that I need it!

tim



On 04/11/2019 16:48, Nathan Dunn wrote:

Tim,

Would allowing a specified user group to be added by default upon registration work? 


Conversely, maybe you want the default group to be dependent on the user_name (which might include ‘*').

Nathan


On Nov 4, 2019, at 8:39 AM, Tim Stickland <[hidden email]> wrote:

A nice thought, but unfortunately I don't know who the users will be.  The notion is to trust an identity provider, and allow a certain level of access to everyone who can log in via that provider.

For the benefit of anyone reading this, for who that may be an answer:  bear in mind that users who arrive via OpenIDC authentication have a user ID of the form [hidden email].     It might be possible to retrieve user profile information from their identity provider afterwards, and that would give you their identity IRL, but this is an operation that has to be done after they log in for the first time -- which brings us back to where we started :)

(Other forms of Remote User authentication may of course give you an email address as user ID, in which case you're off to a good start.)

tim



On 04/11/2019 15:47, Helena Rasche wrote:
Since it sounds like you might know your users ahead of time, maybe if you know their email address, you could pre-create the account + grant access to the correct organisms?

logging in with remote user afterwards should just overwrite first/last name associated with that account.


But I guess in general I have the same problem, "drive by users" who might want to see what it looks like can't see anything and it would be nice if they could add least have viewer permissions on any organism marked "public", so we could mark a demo organism public and everyone could at least see it.

On 04.11.19 15:03, Tim Stickland wrote:
Now I have Remote User Authentication working in Apollo, I have a new problem regarding organism access.

Until now, I have used the API to create user accounts, and granted access to organisms (generally by adding them to a pre-existing group) right after creating the account.  The creation of the account and granting of access rights isn't synchronous, but that's OK as I perform these actions and then give the account details to the end user afterwards.

The issue with Remote User Authentication is that a new user account is created automatically the first time an end user logs in.  As this is an event triggered by the end user, it results in them having an Apollo session before I have the chance to grant organism access.   So they are logged in but with no access to anything :(

I can give the user access using the API, but I don't have the chance to do this until after their Apollo session starts --  so their first session will always result in them being greeted with a dialog telling them they have no permission to see anything. All I can do is create some process whereby they come back later on after I have "activated" the account.  Even if I can automate this so it occurs within minutes, or even within a few seconds, it will still be too late to stop users experiencing an initial session with no access.

A perfect solution would be to have an event that was triggered in between the creation of a new Remote User account, and the initiation of their session.  I don't think Apollo has any such hook, but hey, I thought I'd mention it in case Nathan is feeling particularly industrious ;)

Another solution be to have some sort of default level of access that was granted to all authorized users -- either an "any authorized user" group into which all users were placed when they log in, or simply the ability to configure default levels of organism access.    I've read through the Apollo documentation on organism access/group membership, and I don't think this is supported?

Have I missed something?  (Hopefully!)    Or will I have to grant organism/group access to user accounts as a separate action, at some point after they are created?

thanks

Tim







-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.



-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

--
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: organism access/group membership for newly created Remote User accounts. [EXT]

nathandunn

Sounds good.  Hope to get that in the newest release. 

Nathan


On Nov 5, 2019, at 1:51 AM, Tim Stickland <[hidden email]> wrote:

what you suggest in #2302 would be fine for me, thanks

The option to allocated membership of group(s) depending on user ID would be very nice to have, in theory, but I guess it would be a lot more work -- and I can't honestly say that I need it!

tim



On 04/11/2019 16:48, Nathan Dunn wrote:

Tim,

Would allowing a specified user group to be added by default upon registration work? 


Conversely, maybe you want the default group to be dependent on the user_name (which might include ‘*').

Nathan


On Nov 4, 2019, at 8:39 AM, Tim Stickland <[hidden email]> wrote:

A nice thought, but unfortunately I don't know who the users will be.  The notion is to trust an identity provider, and allow a certain level of access to everyone who can log in via that provider.

For the benefit of anyone reading this, for who that may be an answer:  bear in mind that users who arrive via OpenIDC authentication have a user ID of the form [hidden email].     It might be possible to retrieve user profile information from their identity provider afterwards, and that would give you their identity IRL, but this is an operation that has to be done after they log in for the first time -- which brings us back to where we started :)

(Other forms of Remote User authentication may of course give you an email address as user ID, in which case you're off to a good start.)

tim



On 04/11/2019 15:47, Helena Rasche wrote:
Since it sounds like you might know your users ahead of time, maybe if you know their email address, you could pre-create the account + grant access to the correct organisms? 

logging in with remote user afterwards should just overwrite first/last name associated with that account. 


But I guess in general I have the same problem, "drive by users" who might want to see what it looks like can't see anything and it would be nice if they could add least have viewer permissions on any organism marked "public", so we could mark a demo organism public and everyone could at least see it. 

On 04.11.19 15:03, Tim Stickland wrote: 
Now I have Remote User Authentication working in Apollo, I have a new problem regarding organism access. 

Until now, I have used the API to create user accounts, and granted access to organisms (generally by adding them to a pre-existing group) right after creating the account.  The creation of the account and granting of access rights isn't synchronous, but that's OK as I perform these actions and then give the account details to the end user afterwards. 

The issue with Remote User Authentication is that a new user account is created automatically the first time an end user logs in.  As this is an event triggered by the end user, it results in them having an Apollo session before I have the chance to grant organism access.   So they are logged in but with no access to anything :( 

I can give the user access using the API, but I don't have the chance to do this until after their Apollo session starts --  so their first session will always result in them being greeted with a dialog telling them they have no permission to see anything. All I can do is create some process whereby they come back later on after I have "activated" the account.  Even if I can automate this so it occurs within minutes, or even within a few seconds, it will still be too late to stop users experiencing an initial session with no access. 

A perfect solution would be to have an event that was triggered in between the creation of a new Remote User account, and the initiation of their session.  I don't think Apollo has any such hook, but hey, I thought I'd mention it in case Nathan is feeling particularly industrious ;) 

Another solution be to have some sort of default level of access that was granted to all authorized users -- either an "any authorized user" group into which all users were placed when they log in, or simply the ability to configure default levels of organism access.    I've read through the Apollo documentation on organism access/group membership, and I don't think this is supported? 

Have I missed something?  (Hopefully!)    Or will I have to grant organism/group access to user accounts as a separate action, at some point after they are created? 

thanks 

Tim 







-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. 



-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. 

--
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: organism access/group membership for newly created Remote User accounts. [EXT]

t.r.stickland@sanger.ac.uk
Thanks; much appreciated!

tim


On 05/11/2019 15:17, Nathan Dunn wrote:

Sounds good.  Hope to get that in the newest release. 

Nathan


On Nov 5, 2019, at 1:51 AM, Tim Stickland <[hidden email]> wrote:

what you suggest in #2302 would be fine for me, thanks

The option to allocated membership of group(s) depending on user ID would be very nice to have, in theory, but I guess it would be a lot more work -- and I can't honestly say that I need it!

tim



On 04/11/2019 16:48, Nathan Dunn wrote:

Tim,

Would allowing a specified user group to be added by default upon registration work? 


Conversely, maybe you want the default group to be dependent on the user_name (which might include ‘*').

Nathan


On Nov 4, 2019, at 8:39 AM, Tim Stickland <[hidden email]> wrote:

A nice thought, but unfortunately I don't know who the users will be.  The notion is to trust an identity provider, and allow a certain level of access to everyone who can log in via that provider.

For the benefit of anyone reading this, for who that may be an answer:  bear in mind that users who arrive via OpenIDC authentication have a user ID of the form [hidden email].     It might be possible to retrieve user profile information from their identity provider afterwards, and that would give you their identity IRL, but this is an operation that has to be done after they log in for the first time -- which brings us back to where we started :)

(Other forms of Remote User authentication may of course give you an email address as user ID, in which case you're off to a good start.)

tim



On 04/11/2019 15:47, Helena Rasche wrote:
Since it sounds like you might know your users ahead of time, maybe if you know their email address, you could pre-create the account + grant access to the correct organisms? 

logging in with remote user afterwards should just overwrite first/last name associated with that account. 


But I guess in general I have the same problem, "drive by users" who might want to see what it looks like can't see anything and it would be nice if they could add least have viewer permissions on any organism marked "public", so we could mark a demo organism public and everyone could at least see it. 

On 04.11.19 15:03, Tim Stickland wrote: 
Now I have Remote User Authentication working in Apollo, I have a new problem regarding organism access. 

Until now, I have used the API to create user accounts, and granted access to organisms (generally by adding them to a pre-existing group) right after creating the account.  The creation of the account and granting of access rights isn't synchronous, but that's OK as I perform these actions and then give the account details to the end user afterwards. 

The issue with Remote User Authentication is that a new user account is created automatically the first time an end user logs in.  As this is an event triggered by the end user, it results in them having an Apollo session before I have the chance to grant organism access.   So they are logged in but with no access to anything :( 

I can give the user access using the API, but I don't have the chance to do this until after their Apollo session starts --  so their first session will always result in them being greeted with a dialog telling them they have no permission to see anything. All I can do is create some process whereby they come back later on after I have "activated" the account.  Even if I can automate this so it occurs within minutes, or even within a few seconds, it will still be too late to stop users experiencing an initial session with no access. 

A perfect solution would be to have an event that was triggered in between the creation of a new Remote User account, and the initiation of their session.  I don't think Apollo has any such hook, but hey, I thought I'd mention it in case Nathan is feeling particularly industrious ;) 

Another solution be to have some sort of default level of access that was granted to all authorized users -- either an "any authorized user" group into which all users were placed when they log in, or simply the ability to configure default levels of organism access.    I've read through the Apollo documentation on organism access/group membership, and I don't think this is supported? 

Have I missed something?  (Hopefully!)    Or will I have to grant organism/group access to user accounts as a separate action, at some point after they are created? 

thanks 

Tim 







-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. 



-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. 



-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

--
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: organism access/group membership for newly created Remote User accounts. [EXT]

nathandunn

I was just about to start working on this, but then I realized that it had already been done by Anthony, who I believe had already run into this problem:


Thanks Anthony!   You just specify as below. 

authentications = [
        [
            "name":"Remote User Authenticator",
            "className":"remoteUserAuthenticatorService",
            "active":true,
            "params":["default_group": "annotators"]
        ],
        [
            "name":"Username Password Authenticator",
            "className":"usernamePasswordAuthenticatorService",
            "active":true,
            "params":[]
        ]
    ]


Nathan


On Nov 5, 2019, at 8:54 AM, Tim Stickland <[hidden email]> wrote:

Thanks; much appreciated!

tim


On 05/11/2019 15:17, Nathan Dunn wrote:

Sounds good.  Hope to get that in the newest release. 

Nathan


On Nov 5, 2019, at 1:51 AM, Tim Stickland <[hidden email]> wrote:

what you suggest in #2302 would be fine for me, thanks

The option to allocated membership of group(s) depending on user ID would be very nice to have, in theory, but I guess it would be a lot more work -- and I can't honestly say that I need it!

tim



On 04/11/2019 16:48, Nathan Dunn wrote:

Tim,

Would allowing a specified user group to be added by default upon registration work? 


Conversely, maybe you want the default group to be dependent on the user_name (which might include ‘*').

Nathan


On Nov 4, 2019, at 8:39 AM, Tim Stickland <[hidden email]> wrote:

A nice thought, but unfortunately I don't know who the users will be.  The notion is to trust an identity provider, and allow a certain level of access to everyone who can log in via that provider.

For the benefit of anyone reading this, for who that may be an answer:  bear in mind that users who arrive via OpenIDC authentication have a user ID of the form [hidden email].     It might be possible to retrieve user profile information from their identity provider afterwards, and that would give you their identity IRL, but this is an operation that has to be done after they log in for the first time -- which brings us back to where we started :)

(Other forms of Remote User authentication may of course give you an email address as user ID, in which case you're off to a good start.)

tim



On 04/11/2019 15:47, Helena Rasche wrote:
Since it sounds like you might know your users ahead of time, maybe if you know their email address, you could pre-create the account + grant access to the correct organisms? 

logging in with remote user afterwards should just overwrite first/last name associated with that account. 


But I guess in general I have the same problem, "drive by users" who might want to see what it looks like can't see anything and it would be nice if they could add least have viewer permissions on any organism marked "public", so we could mark a demo organism public and everyone could at least see it. 

On 04.11.19 15:03, Tim Stickland wrote: 
Now I have Remote User Authentication working in Apollo, I have a new problem regarding organism access. 

Until now, I have used the API to create user accounts, and granted access to organisms (generally by adding them to a pre-existing group) right after creating the account.  The creation of the account and granting of access rights isn't synchronous, but that's OK as I perform these actions and then give the account details to the end user afterwards. 

The issue with Remote User Authentication is that a new user account is created automatically the first time an end user logs in.  As this is an event triggered by the end user, it results in them having an Apollo session before I have the chance to grant organism access.   So they are logged in but with no access to anything :( 

I can give the user access using the API, but I don't have the chance to do this until after their Apollo session starts --  so their first session will always result in them being greeted with a dialog telling them they have no permission to see anything. All I can do is create some process whereby they come back later on after I have "activated" the account.  Even if I can automate this so it occurs within minutes, or even within a few seconds, it will still be too late to stop users experiencing an initial session with no access. 

A perfect solution would be to have an event that was triggered in between the creation of a new Remote User account, and the initiation of their session.  I don't think Apollo has any such hook, but hey, I thought I'd mention it in case Nathan is feeling particularly industrious ;) 

Another solution be to have some sort of default level of access that was granted to all authorized users -- either an "any authorized user" group into which all users were placed when they log in, or simply the ability to configure default levels of organism access.    I've read through the Apollo documentation on organism access/group membership, and I don't think this is supported? 

Have I missed something?  (Hopefully!)    Or will I have to grant organism/group access to user accounts as a separate action, at some point after they are created? 

thanks 

Tim 







-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. 



-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. 



-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

--
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: organism access/group membership for newly created Remote User accounts. [EXT]

t.r.stickland@sanger.ac.uk
That's excellent, thanks.  Exactly what I needed!

For anyone reading this thread who may be interested in turning this on:   I discovered along the way that this will only add users to the default group when their account in created, at the first log in.   Existing "remote user" accounts will not get added to the group.   I don't think this is a big deal, as existing accounts can have group membership added easily using the API -- the problem that needed to be fixed was to configure access for the accounts that do not yet exist.

Tim



On 05/11/2019 17:13, Nathan Dunn wrote:

I was just about to start working on this, but then I realized that it had already been done by Anthony, who I believe had already run into this problem:


Thanks Anthony!   You just specify as below. 

authentications = [
        [
            "name":"Remote User Authenticator",
            "className":"remoteUserAuthenticatorService",
            "active":true,
            "params":["default_group": "annotators"]
        ],
        [
            "name":"Username Password Authenticator",
            "className":"usernamePasswordAuthenticatorService",
            "active":true,
            "params":[]
        ]
    ]


Nathan


On Nov 5, 2019, at 8:54 AM, Tim Stickland <[hidden email]> wrote:

Thanks; much appreciated!

tim


On 05/11/2019 15:17, Nathan Dunn wrote:

Sounds good.  Hope to get that in the newest release. 

Nathan


On Nov 5, 2019, at 1:51 AM, Tim Stickland <[hidden email]> wrote:

what you suggest in #2302 would be fine for me, thanks

The option to allocated membership of group(s) depending on user ID would be very nice to have, in theory, but I guess it would be a lot more work -- and I can't honestly say that I need it!

tim



On 04/11/2019 16:48, Nathan Dunn wrote:

Tim,

Would allowing a specified user group to be added by default upon registration work? 


Conversely, maybe you want the default group to be dependent on the user_name (which might include ‘*').

Nathan


On Nov 4, 2019, at 8:39 AM, Tim Stickland <[hidden email]> wrote:

A nice thought, but unfortunately I don't know who the users will be.  The notion is to trust an identity provider, and allow a certain level of access to everyone who can log in via that provider.

For the benefit of anyone reading this, for who that may be an answer:  bear in mind that users who arrive via OpenIDC authentication have a user ID of the form [hidden email].     It might be possible to retrieve user profile information from their identity provider afterwards, and that would give you their identity IRL, but this is an operation that has to be done after they log in for the first time -- which brings us back to where we started :)

(Other forms of Remote User authentication may of course give you an email address as user ID, in which case you're off to a good start.)

tim



On 04/11/2019 15:47, Helena Rasche wrote:
Since it sounds like you might know your users ahead of time, maybe if you know their email address, you could pre-create the account + grant access to the correct organisms? 

logging in with remote user afterwards should just overwrite first/last name associated with that account. 


But I guess in general I have the same problem, "drive by users" who might want to see what it looks like can't see anything and it would be nice if they could add least have viewer permissions on any organism marked "public", so we could mark a demo organism public and everyone could at least see it. 

On 04.11.19 15:03, Tim Stickland wrote: 
Now I have Remote User Authentication working in Apollo, I have a new problem regarding organism access. 

Until now, I have used the API to create user accounts, and granted access to organisms (generally by adding them to a pre-existing group) right after creating the account.  The creation of the account and granting of access rights isn't synchronous, but that's OK as I perform these actions and then give the account details to the end user afterwards. 

The issue with Remote User Authentication is that a new user account is created automatically the first time an end user logs in.  As this is an event triggered by the end user, it results in them having an Apollo session before I have the chance to grant organism access.   So they are logged in but with no access to anything :( 

I can give the user access using the API, but I don't have the chance to do this until after their Apollo session starts --  so their first session will always result in them being greeted with a dialog telling them they have no permission to see anything. All I can do is create some process whereby they come back later on after I have "activated" the account.  Even if I can automate this so it occurs within minutes, or even within a few seconds, it will still be too late to stop users experiencing an initial session with no access. 

A perfect solution would be to have an event that was triggered in between the creation of a new Remote User account, and the initiation of their session.  I don't think Apollo has any such hook, but hey, I thought I'd mention it in case Nathan is feeling particularly industrious ;) 

Another solution be to have some sort of default level of access that was granted to all authorized users -- either an "any authorized user" group into which all users were placed when they log in, or simply the ability to configure default levels of organism access.    I've read through the Apollo documentation on organism access/group membership, and I don't think this is supported? 

Have I missed something?  (Hopefully!)    Or will I have to grant organism/group access to user accounts as a separate action, at some point after they are created? 

thanks 

Tim 







-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. 



-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. 



-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.


-- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

--
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].