Future of workflow states
4 views
Skip to first unread message
Thijs Kinkhorst
Jul 16, 2019, 10:10:45 AM7/16/19
to OpenConext Community
Hi all,
Engine and manage currently support "workflow states" for entities, the
default available states are for historical reasons named "prodaccepted"
and "testaccepted".
What it does is that only two entities that have the same workflow state
can work together, that is, only IdPs in state "A" can log into SPs in
state "A", and those IdPs cannot login to SPs in state "B".
Problem with this functionality is that it's rather partially implemented.
EB and Manage know about it, but other parts of the system do not. So e.g.
OIDC RPs or Stepup entities must always have state 'prodaccepted' to work.
We have also found that it's very confusing to the remote entity
administrators. They cannot see the state of their entity and therefore
are confused why some IdPs work and others don't. And how this relates to
ACLs. Because limitations of which IdP can access which SP can of course
also already be defined with the ACLs. So we've stopped using them.
Workflow states complicate the EB processing code a lot. We think there's
quite significant savings to make by obsoleting the feature, and we
believe that EB as the core of the platform should be as clean and
straightforward as possible.
Of course we'd be interested to hear thoughts of others about this feature.
Cheers,
Thijs
Engine and manage currently support "workflow states" for entities, the
default available states are for historical reasons named "prodaccepted"
and "testaccepted".
What it does is that only two entities that have the same workflow state
can work together, that is, only IdPs in state "A" can log into SPs in
state "A", and those IdPs cannot login to SPs in state "B".
Problem with this functionality is that it's rather partially implemented.
EB and Manage know about it, but other parts of the system do not. So e.g.
OIDC RPs or Stepup entities must always have state 'prodaccepted' to work.
We have also found that it's very confusing to the remote entity
administrators. They cannot see the state of their entity and therefore
are confused why some IdPs work and others don't. And how this relates to
ACLs. Because limitations of which IdP can access which SP can of course
also already be defined with the ACLs. So we've stopped using them.
Workflow states complicate the EB processing code a lot. We think there's
quite significant savings to make by obsoleting the feature, and we
believe that EB as the core of the platform should be as clean and
straightforward as possible.
Of course we'd be interested to hear thoughts of others about this feature.
Cheers,
Thijs
Joe Topjian
Jul 17, 2019, 11:49:27 AM7/17/19
to openc...@googlegroups.com
Hello,
We (Pika) use this feature for onboarding IdPs and SPs so they can verify functionality before being promoted to production. However, we can also have IdPs and SPs connect to a dev or demo environment (entirely separate set of infrastructure) of our federation and achieve the same thing.
So we're OK with having this removed.
Thank you for checking!
Joe
--
OpenConext - Open For Collaboration
---
You received this message because you are subscribed to the Google Groups "OpenConext Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openconext+...@googlegroups.com.
To post to this group, send email to openc...@googlegroups.com.
Visit this group at https://groups.google.com/group/openconext.
To view this discussion on the web visit https://groups.google.com/d/msgid/openconext/f3f1549c-2602-9000-3c9d-11dedc4a2ff5%40surfnet.nl.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages