Re: [Unity-idm-discuss] Unity as UNICORE/X attribute source

[Krzysztof B. <go...@ic...>]

Hi Björn,

W dniu 06.02.2015 o 14:04, Björn Hagemeier pisze:
> Hi all,
>
> last summer (July 10), Krzysztof reported that pull mode should be
> possible acc. to the UNICORE/X documentation. However, I found some
> missing bits and pieces to really make it work (for me). As far as I can
> see from my changes in the unityServer.conf, the most important
> configuration is to allow certificate based authentication on the
> SAMLUnicoreSoapIdP endpoint. In order to achieve that, I needed a certWS
> authenticator, which seemed to have been missing so far.
>
> Here's a diff of the relevant portions in unityServer.conf:
>
> ==================================================
> +unityServer.core.authenticators.5.authenticatorName=certWS
> +unityServer.core.authenticators.5.authenticatorType=certificate with
> cxf-certificate
> +unityServer.core.authenticators.5.localCredential=Certificate credential
> +unityServer.core.authenticators.5.retrievalConfigurationFile=conf/authenticators/empty.json
> [...]	
>   unityServer.core.endpoints.4.endpointType=SAMLUnicoreSoapIdP
> -unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-webidp.properties
> +unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-unicoreidp.properties
>   unityServer.core.endpoints.4.contextPath=/unicore-soapidp
>   unityServer.core.endpoints.4.endpointRealm=defaultRealm
>   unityServer.core.endpoints.4.endpointName=UNITY UNICORE SOAP SAML service
> -unityServer.core.endpoints.4.endpointAuthenticators=pwdWS
> +unityServer.core.endpoints.4.endpointAuthenticators=certWS;pwdWS
>   ==================================================
>
> This configuration is working well for me. However, I am wondering
> whether this can be correct or is even required. After all I guessed the
> setup of the additional authenticator and the changes to the endpoint.
> Ok, looking back into the documentation (Sect. 3.5) I do see the
> relevant snippet, though the example is not quite right (s/pwdWS/certWS/).
>
> The endpoint for the AssertionQueryService needs to be guessed. Maybe it
> is obvious for knowledgeable people, but it does not appear in either
> the Unity or the UNICORE/X manual.

Regarding this part:
1) the typo in section 3.5 of documentation was fixed, thanks for 
spotting it

2) regarding the *default* configuration of the UNICORE SOAP Idp 
endpoint, what you have in the distro is suited for use with UCC and 
cert-less login. Your changes to enable the pull mode from the server 
are correct: UNICORE server can identify itself only with a certificate 
so certificate authenticator is required.
That's said I don't see any problem with changing the defaults here, 
i.e. to add a 'certWS' authenticator to the default configuration. Will 
be in the next release.

3) Endpoint address - right, it is not trivial to find it. You can see 
the base path of the address in the Server Management->Endpoints tab, 
after expanding the appropriate endpoint. You have to open this base 
address: CXF reports all the services, including the detailed addresses.


And yes, you are right - there is no UNICORE+Unity howto, and it is 
needed. The address should be provided there.


> Which are the settings for the services consuming attributes? Which
> roles do they need? Can they have local roles within a VO/Group? Acc. to
> the developer Wiki there are (were?) issues with this setup as well as
> the setup for group administration[1]. Do services need to be members of
> the groups which they query? How do I best set their xlogin (nobody?) if
> I want to use an attribute class requiring xlogin and role to be set?

The settings should be the same as in case of using any other attribute 
source. In most cases the role should be 'server' and xlogin unset or 
nobody - however this depends on a site.

You can set the local roles in a group - this is a generic Unity 
feature, always available.

The issues mentioned in the developer's oriented wiki are related to a 
limited authorization of Unity management. I.e. there are some 
limitations if you want to have a person who can administer only a 
specific group of Unity groups tree.

No, services (and all other clients) need not to be members of groups 
they query. They need to have read permission there. So they need (at 
least) read permission on the group or on any of parent group.

There are many possible approaches to set xlogin and role for services 
and users, this really depends on your scenario. Couple of hints:
- If you have different mappings per site then create group for each site.
- Use group attribute statements to assign default or common values.
- Also to copy attributes to have uniform view.

Consider a quite sophisticated example:

/siteA/servers <- all servers with attribute statement assigning fixed 
role=server and xlogin=nobody
/siteA/users <- all users, attribute statement assigning role=user and 
xlogin set individually
/siteA <- used in endpoint's configuration. Has attribute statements 
that copy the role and xlogin attribute from servers and users subgroups.

> BTW, speaking of attribute classes. It is quite some hassle to modify an
> attribute class for any given group. I think I do understand why this is
> so, but from the point of view of usability it seems like a nightmare
> (please don't take this as an offense). I did find a workaround
> (temporary group), but maybe that should not be required. This is more
> of a general issue than a UNICORE specific one. I haven't had a look at
> the latest release 1.5.0 yet, maybe some of that has gone by now.

Hard to comment - what is the problem? If you want to set mandatory 
attributes requirement it is a hassle by definition (mandatory is 
mandatory, dot). Rule of thumb: use mandatory attributes *only* for 
attributes that you have to define manually, and the attribute really 
must be always set. Attributes which have sensible defaults, especially 
those assigned by attribute statements, should be included in the 
'allowed' enumeration of the class.


> Once these issues have been sorted out, I'd like to provide a concise
> howto on the relevant steps to get UNICORE/X going with UNITY as the
> attribute source. IMO, this is a very valuable use case, but the
> description not fully there, at least not in one piece.
Yes, this is a very much needed effort. Of course I'll contribute.

Cheers,
Krzysztof